这一策略源于我尝试围绕价值流设计架构的探索：独立团队需要拥有、开发、测试并部署他们自己的代码。一旦变更准备就绪可以发布，他们只需提升其工作成果。此时，运行时会将他们的最新变更动态加载到产品中。然而，仅有独立性是不够的。如果实现独立性要求每个团队都理解一个复杂的组合框架，或维护多层专用配置，那么这种架构只不过是用认知负荷换取了交付摩擦。我希望构建一种基于小型共享约定的策略——在保持团队自主权的同时，确保整个系统易于理解。这一探索最终引导我将浏览器原生原语，特别是 ES 模块和导入映射，作为运行时模块组合的基础。
如果你曾参与大型 Web 产品的开发，可能经历过这样的场景：五个团队负责同一个页面，构建流水线中的 webpack 配置已经复杂到无人能完全理解，微小的变更就会触发整套测试。将页面拆分为独立构建、独立部署的片段，本意是为了解决“五个团队，一个页面”的问题。但在实践中，大多数微前端工具库只是在此基础上又增加了另一层构建时的复杂性。
其实，每个现代浏览器中都已经存在一个更简单的答案：导入映射。它允许页面声明“当有人导入 react 时，实际上从这个 URL 获取它”，无需打包工具，无需自定义模块加载器，也无需 iframe。运行时模块组合 是一个完全围绕这一浏览器特性构建的小型工具包（rmc-toolkit）。本文将介绍它的功能，并解释为何这种浏览器原生方法最终比听起来更简单。
一句话概括问题
由不同团队构建的片段组成的页面需要两样东西：一种为当前 URL 找到正确片段的方法，以及一种在不打包五份 React 副本的情况下加载它的方法。大多数解决方案都是从零开始构建这两者。而导入映射可以免费为你提供这两者。
导入映射究竟是什么
抛开名称不谈，它只是一个查找表，以 <script> 标签的形式编写：
<script type="importmap">
{
"imports": {
"react": "https://esm.sh/react@19.1.0",
"@fastflights/search/": "https://assets.fastflights.com/search/"
}
}
</script>
当页面上的任何 JavaScript 代码随后编写 import React from "react" 时，浏览器会在该表中查找 "react" 并获取真实的 URL，这是一个普通的 HTTP 请求，不涉及任何构建步骤。这是 Web 平台中真正的标准化部分，并非某个库发明的特性。如今，所有主流浏览器都支持它。
这就是全部的窍门。本文其余内容实际上只是在探讨：你在这个查找表之上构建什么
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
