远程组件，即运行时可以远程拉取的组件，并不在打包时之间打入项目的dist中。其最基本的原理是，将组件打包为umd格式js，上传到oss得到远程链接，之后可以通过动态创建script标签形式动态引入该组件。 实现可以参考hel-micro 的方案，我司也是基于这套方案进行了定制的。

此文并不是介绍远程组件的原理和设计方案，只是记录一下个人感想：技术之外还有更多的问题需要考虑。

远程组件的优点

远程组件一方面可以节约打包体积，做到按需使用；另一方面它的更新可以不受项目迭代周期限制。另外，如果一个组件被多个项目引入，普通组件如果改动，那么这些项目都需要进行CICD，而远程组件则能节省这部分时间。

远程组件实践中的问题远程组件升级风险

大规模使用的，且更新频繁的组件，并不适合远程加载。

我司最初引入远程组件，就是为了节省项目CICD的频次。

整体系统大致如下，组件管理平台可以升级、回滚远程组件的版本。

但实践并不如预期：我有一个大规模使用的核心组件，每周迭代频次很高，但改造后，我也没有推广这个组件的远程版本，因为这个组件过于复杂，没有把握升级不出问题，所以最安全的方式是项目上自己手动按需升级。最终这个远程组件进在小部分项目中使用，没有达到目标。

低代码平台物料包管理

物料包就是低代码平台可视化搭建器的额外组件包。

这套设计初衷是让产线可以自行将业务组件改造为物料包原料上传给低代码平台。这个场景和远程组件的特点非常契合，但在我司的实践中也遇到了问题：业务产线并无意愿封装/改造组件。

这个决策的最大的错误是忽视了效率。因为我司低代码平台的二开机制比较完善，产线的开发者通过二开+复制代码的方式就能实现；而接入物料包，既要封装或改造组件，还需要在平台上进行配置，无论是体验还是效率都不如前者。

总结

个人感觉，如果从ROI的角度我司在远程组件的实践中并没有获得多少收益，但这两件事本身也是有价值的——当我们的测试质量和测试覆盖率达到一个比较高的水平，当规模越来越大，当低代码开发者成为公司主体的时候......