Module Federation中为何从远程端加载共享库？

首先明确一个常见认知误区：Module Federation 没有默认「共享库优先从host加载」的规则，它的共享模块调度逻辑核心是「先保证运行正确性，再做加载性能优化」，出现从remote拉取共享库的情况，都是触发了预设的 fallback 逻辑，常见场景有四类：

• 版本范围不匹配
  每个应用（不管是host还是remote）在shared配置中声明共享库时，都会带上自身依赖要求的版本范围。比如host侧提供的react版本是17.0.2，但remote侧声明自己依赖的react版本要求是>=18.0.0，host提供的版本不满足remote的最低版本要求，调度逻辑就会放弃host的共享实例，直接从remote端拉取符合版本要求的库文件。
• 单例模式下的加载时序问题
  对于react、vue这类必须全局单例运行的库，一般会配置singleton: true，正常规则是哪个端先把库实例注册到全局共享scope，后续所有端都复用这个实例。但如果remote的业务代码执行时机早于host的共享scope初始化逻辑，此时共享scope里还没有host注册的库实例，就会先加载remote自带的库版本，后续host初始化时发现已经存在单例实例，也不会重复加载覆盖。
• host端未声明对应共享依赖
  如果host的Module Federation配置里根本没有把某一个库加入shared列表，哪怕remote侧配置了这个库为共享依赖，host也无法对外提供这个库的实例，remote自然只能加载自身打包时内置的对应库文件。
• 非eager模式下的加载时序差
  共享库默认是eager: false配置，也就是不会在应用启动时同步加载，而是按需异步加载。如果remote的入口chunk加载完成开始执行时，host侧对应的共享库chunk还没下载完成、没注册到共享scope，调度逻辑就会临时fallback到remote自带的库资源，避免阻塞应用运行。

关于「优先从host加载性能更好」的认知纠正 #

很多人觉得强制复用host的共享库能减少跨端请求、性能更好，实际上这个逻辑只有在「版本匹配、加载时序对齐」的前提下才成立：

共享调度的第一优先级是保证应用不报错，其次才是性能优化。如果强制优先使用host的库，一旦版本不兼容直接导致remote运行崩溃，属于功能性故障，优先级远高于多加载一次资源的性能损耗。

如果确实要尽可能优先复用host的共享库、减少从remote拉取的情况，可以通过配置手动实现：

1. 给所有共享库配置eager: true，让host启动时就把所有共享库同步注册到全局共享scope，避免时序差问题
2. 对齐host和所有remote的共享库版本，保证host提供的版本满足所有remote的版本范围要求
3. 给host侧的共享库配置更高的priority权重，在多端都提供同版本符合要求的共享实例时，优先选用host注册的实例

内容的提问来源于stack exchange，提问作者ZhaoWei