Module Federation 动态加载是怎么实现的？

Module Federation 的动态加载，本质是 host 在运行时先加载 remoteEntry.js，再从远程容器里取出指定模块工厂，最后执行工厂拿到组件或函数。它的优势是部署和加载都更灵活：用户没访问某个功能，就不必下载对应代码；remote 更新后，也不一定要求 host 重新构建。但动态加载不是免费午餐，它会引入网络失败、版本协商、加载顺序和降级体验这些运行时问题。

追问

它和普通 import() 有什么区别？

普通 import() 加载的是当前构建产物里的异步 chunk，构建时 Webpack 已经知道依赖图。Module Federation 的 import('remote/Button') 则会通过容器引用去远程应用拿模块，host 构建时只知道远程容器名和暴露路径。取舍是它换来了跨应用复用和独立部署，但也把一部分确定性从构建时挪到了运行时。踩坑是本地开发能加载，不代表生产可用，生产还要处理域名、CORS、缓存和版本地址。

运行时远程地址可以动态决定吗？

可以，常见做法是用 promise remote 或在启动前拉一份 manifest，根据环境、租户、灰度批次决定 remoteEntry 地址。这样适合多环境部署和灰度发布，但配置源必须高可用，否则 host 连入口都找不到。边界是不要把远程地址完全交给用户输入或不可信接口，避免加载未知脚本带来安全风险。实际项目里通常会做白名单、版本签名和超时兜底。

js
remotes: {
  shop: `promise new Promise(resolve => {
    const url = window.__REMOTE_MANIFEST__.shop;
    const s = document.createElement('script');
    s.src = url;
    s.onload = () => resolve(window.shop);
    document.head.appendChild(s);
  })`
}

React 里动态加载 remote 组件怎么做更稳？

React.lazy 可以直接包远程模块，但必须配合 Suspense 和 ErrorBoundary，否则网络失败时页面会白屏。加载态要按业务重要性设计，主流程组件失败时应该给重试或降级入口，边缘运营组件失败可以直接隐藏。取舍是通用加载器能减少重复代码，但过度封装会掩盖具体错误，排查时反而困难。建议在加载器里统一打点 remote 名称、模块名、耗时和异常类型。

动态加载会不会影响首屏？

如果首屏依赖 remote，它当然会影响，因为浏览器必须先拿 remoteEntry，再拿模块 chunk，链路比本地 chunk 更长。解决方式不是一律禁止首屏 remote，而是把关键 remote 做预连接、预加载或服务端下发就近 CDN 地址。边界是首页骨架、导航和错误提示最好由 host 自己掌握，不能让远程失败拖垮整个壳。很多团队踩过的坑是把布局组件也远程化，结果某个 remote 挂了，全站都打不开。

动态加载适合哪些场景？

它适合权限差异大、访问频率不均、团队需要独立发布的功能，比如后台插件、低频设置页、营销活动页和大型可视化组件。不适合强一致、强首屏、频繁跨模块同步状态的核心链路，除非团队能接受额外的治理成本。优势在组织协作上很明显，但技术边界也要讲清楚：动态加载解决的是代码交付问题，不自动解决状态管理、样式隔离和接口契约问题。把它当成模块级发布能力，而不是微前端万能胶，会少踩很多坑。