程式發展的必然方向，就是外掛化；
https://tech.meituan.com/2019/12/19/meituan-mrn-practice.html
程式發展一定會經歷的階段：
- 業務要求快速發版試錯和原生迭代週期長；
- 必須搭建自己的開放平臺，而搭建自己的開放平臺，要麼使用小程式來擴充套件，要麼使用原生語言外掛；
- 若不使用外掛化，業務持續增長帶來的安裝包的大幅增長，且每次一個小更新，使用者就需要更新整個安裝包；
- 內部難以並行開發，外部開放平臺的開發者更是如此；
小程式 為什麼不使用 外掛的方式，而是使用 js + web技術棧
小程式之所以選擇使用 JavaScript（JS）結合 Web 技術棧，而不是完全依賴於外掛方式，主要有以下幾個方面的原因：
-
跨平臺相容性：
- JS + Web 技術棧（HTML、CSS）是一種廣泛被採用的標準，具有良好的跨平臺相容性。這意味著無論是在哪種作業系統或裝置上，只要支援這些Web標準，小程式就能夠正常執行。
-
開發效率和成本：
- 使用 JS + Web 可以利用現有的 Web 開發資源和人才庫，降低開發者的學習成本，提高開發效率。同時，這種技術棧的普及度高，有大量的開源庫和框架可供使用，進一步減少了開發難度和時間成本。
-
效能與體驗：
- Web 技術經過多年的發展最佳化，已經能夠提供相當不錯的效能和使用者體驗。小程式透過採用雙執行緒模型（渲染層與邏輯層分離），能夠進一步提升頁面的渲染速度和響應能力，從而為使用者提供接近原生應用的體驗。
-
外掛的限制：
- 雖然外掛可以提供一定的功能擴充套件性，但它們通常是針對特定功能或服務的封裝。完全依賴外掛可能會導致小程式的功能受限於外掛的更新和相容性，而且不同的外掛之間可能存在衝突或整合問題。
-
安全性與可控性：
- 小程式執行在一個受限制的環境中，透過使用 Web 技術棧，平臺可以更好地控制程式碼的執行和資源的訪問，從而提高小程式的安全性。此外，JS 的沙箱環境也能有效隔離不同小程式之間的程式碼和資料，防止相互干擾。
-
更新與維護：
- 使用統一的 Web 技術棧便於小程式的更新和維護。當需要修復bug或新增新功能時，開發者可以更加高效地進行修改和部署，而無需擔心不同外掛之間的相容性問題。
綜上所述，小程式選擇使用 JS + Web 技術棧是出於跨平臺相容性、開發效率、效能體驗、安全性以及更新維護等多方面的考慮。這種選擇使得小程式能夠在各種裝置和作業系統上提供一致且高效的使用者體驗。
是選擇小程式還是選擇原生外掛呢；
原生外掛
優勢：
- 執行速度，功能複雜度；都沒有問題；人才儲備也沒有問題；
劣勢：
-
過渡靈活強大，安全性，收到重大挑戰；因為開發者好比開發原生應用一樣，無所不能；
解決方法：
- 使用gitee，要求所有開發者開發的外掛的程式碼，必須在我們自己的程式碼庫裡，由我們來統一管理這些程式碼；對這些程式碼進行掃描；禁止使用 一些敏感的原生函式或庫；對程式碼進行掃描；
-
不跨平臺，每個作業系統都有自己的原生外掛，就是說開發者開發一個外掛，要若跨平臺需要 使用不同的語言開發多次，這個沒有問題，可以接受；
-
IDE 、編譯器、程式語言版本 不一致導致的問題；比如 delphi 10編譯出的bpl，delphi11就無法相容；
- 解決方法：由於我們控制了所有外掛的程式碼，我們自己的宿主程式 若要升級，則把全網的外掛的程式碼 統一編譯一下，得出新的外掛，就可解決；我們的MySQL裡 有宿主對應的 IDE 編譯器 程式語言版本；
小程式
優勢：
- 跨平臺，web技術棧；
劣勢：
- 執行效率低；
- 功能簡單，只能開發一些簡單的功能，無法開發複雜的功能，所以叫小程式；
- 整個小程式下來，小程式的發明商需要提供IDE測試工具，開發文件與 web技術棧，還不是完全相同；必須用特定的技術和IDE來開發，如 wxxml、wxcss這類與 html、css相似的封裝的東西；
- 小程式提供商，也是需要做的工作挺複雜的，只所以搞這麼複雜就是為了安全；為了安全無底線的複雜下去，不值得，其實完全可以靠機器掃描開發者程式碼或人工稽核的方式，來避免這個問題，蘋果的appstore就是 透過稽核來解決這個問題的，而不是使用web技術棧，再巢狀一層 複雜的技術棧，來解決這個問題；為了安全繞這麼大一圈；這個發明小程式的人，只能說是個技術程式設計師，希望依託技術來解決這一切；沒有意義；沒有站在真正的價值的角度來思考問題；
下班了，改天再寫；