坚决不走小程序，而是走插件化

程序发展的必然方向，就是插件化；

https://tech.meituan.com/2019/12/19/meituan-mrn-practice.html

程序发展一定会经历的阶段：

1. 业务要求快速发版试错和原生迭代周期长；
2. 必须搭建自己的开放平台，而搭建自己的开放平台，要么使用小程序来扩展，要么使用原生语言插件；
3. 若不使用插件化，业务持续增长带来的安装包的大幅增长，且每次一个小更新，用户就需要更新整个安装包；
4. 内部难以并行开发，外部开放平台的开发者更是如此；

小程序 为什么不使用 插件的方式，而是使用 js + web技术栈

小程序之所以选择使用 JavaScript（JS）结合 Web 技术栈，而不是完全依赖于插件方式，主要有以下几个方面的原因：

1. 跨平台兼容性：

   • JS + Web 技术栈（HTML、CSS）是一种广泛被采用的标准，具有良好的跨平台兼容性。这意味着无论是在哪种操作系统或设备上，只要支持这些Web标准，小程序就能够正常运行。

2. 开发效率和成本：

   • 使用 JS + Web 可以利用现有的 Web 开发资源和人才库，降低开发者的学习成本，提高开发效率。同时，这种技术栈的普及度高，有大量的开源库和框架可供使用，进一步减少了开发难度和时间成本。

3. 性能与体验：

   • Web 技术经过多年的发展优化，已经能够提供相当不错的性能和用户体验。小程序通过采用双线程模型（渲染层与逻辑层分离），能够进一步提升页面的渲染速度和响应能力，从而为用户提供接近原生应用的体验。

4. 插件的限制：

   • 虽然插件可以提供一定的功能扩展性，但它们通常是针对特定功能或服务的封装。完全依赖插件可能会导致小程序的功能受限于插件的更新和兼容性，而且不同的插件之间可能存在冲突或整合问题。

5. 安全性与可控性：

   • 小程序运行在一个受限制的环境中，通过使用 Web 技术栈，平台可以更好地控制代码的执行和资源的访问，从而提高小程序的安全性。此外，JS 的沙箱环境也能有效隔离不同小程序之间的代码和数据，防止相互干扰。

6. 更新与维护：

   • 使用统一的 Web 技术栈便于小程序的更新和维护。当需要修复bug或添加新功能时，开发者可以更加高效地进行修改和部署，而无需担心不同插件之间的兼容性问题。

综上所述，小程序选择使用 JS + Web 技术栈是出于跨平台兼容性、开发效率、性能体验、安全性以及更新维护等多方面的考虑。这种选择使得小程序能够在各种设备和操作系统上提供一致且高效的用户体验。

是选择小程序还是选择原生插件呢；

原生插件

优势：

1. 运行速度，功能复杂度；都没有问题；人才储备也没有问题；

劣势：

1. 过渡灵活强大，安全性，收到重大挑战；因为开发者好比开发原生应用一样，无所不能；

   解决方法：

   • 使用gitee，要求所有开发者开发的插件的代码，必须在我们自己的代码库里，由我们来统一管理这些代码；对这些代码进行扫描；禁止使用 一些敏感的原生函数或库；对代码进行扫描；

2. 不跨平台，每个操作系统都有自己的原生插件，就是说开发者开发一个插件，要若跨平台需要 使用不同的语言开发多次，这个没有问题，可以接受；

3. IDE 、编译器、程序语言版本 不一致导致的问题；比如 delphi 10编译出的bpl，delphi11就无法兼容；

   • 解决方法：由于我们控制了所有插件的代码，我们自己的宿主程序 若要升级，则把全网的插件的代码 统一编译一下，得出新的插件，就可解决；我们的MySQL里 有宿主对应的 IDE 编译器 程序语言版本；

小程序

优势：

1. 跨平台，web技术栈；

劣势：

1. 运行效率低；
2. 功能简单，只能开发一些简单的功能，无法开发复杂的功能，所以叫小程序；
3. 整个小程序下来，小程序的发明商需要提供IDE测试工具，开发文档与 web技术栈，还不是完全相同；必须用特定的技术和IDE来开发，如 wxxml、wxcss这类与 html、css相似的封装的东西；
4. 小程序提供商，也是需要做的工作挺复杂的，只所以搞这么复杂就是为了安全；为了安全无底线的复杂下去，不值得，其实完全可以靠机器扫描开发者代码或人工审核的方式，来避免这个问题，苹果的appstore就是 通过审核来解决这个问题的，而不是使用web技术栈，再嵌套一层 复杂的技术栈，来解决这个问题；为了安全绕这么大一圈；这个发明小程序的人，只能说是个技术程序员，希望依托技术来解决这一切；没有意义；没有站在真正的价值的角度来思考问题；

下班了，改天再写；