静态还是动态微前端？

静态和动态微前端的区别，一开始很容易被理解成一个 Configuration 细节：一种方式把 Remote 地址写进配置文件，另一种方式从 Manifest 读取。从纯技术角度看，区别确实可以这么简单地描述。

但从架构角度看，这还远远不够。

真正关键的是绑定发生在什么时候：Host 在什么时间点决定自己要使用哪个 Remote？这个时间点会进一步决定：更换 Remote 是否需要重新 Build Host、不同 Environment 如何区分、Version 如何被激活或回滚，以及哪些错误会从 Build/Release 阶段被推迟到 Runtime 才出现。

所以真正应该问的不只是：

什么是静态绑定，什么是动态绑定？

而是：

我们希望在什么时候决定 Host 实际使用哪个 Remote？

这个决定越晚，运行和发布时的可操作空间通常越大；与此同时，原本能在 Build 阶段确定的事情，会被推迟到 Deployment 或 Runtime。系统因此获得更多灵活性，也必须承担更多配置、组合、故障模式和运行时决策。

静态并不是指“什么时候执行代码”

首先要澄清一个常见误解：静态绑定的微前端，并不意味着 Remote 代码必须被打进 Host Bundle。

即使采用静态绑定，Remote 代码仍然可以等到用户导航到某个功能区域、打开某个页面，或者触发某次具体交互时才从网络加载。

这里所谓“静态”，描述的不是代码什么时候下载或执行。

静态描述的是：Host 在什么时候得到 Remote 的绑定关系。

静态绑定意味着，在 Host Artifact 被构建时，Host 已经知道有哪些 Remote，以及它们通过什么地址、或者按照哪种已经写入 Artifact 的规则来解析：

Host Build
    │
    └── 已知：
        tasks → https://tasks.example.com/remote-entry.js

Host 并不需要把 Remote 一起 Build。它只是提前知道逻辑名称与可访问入口之间的映射。

动态绑定则不同：Host Artifact 在构建完成时还不包含最终映射。这个映射稍后才会被决定，例如在 Deployment、应用启动，或者读取 Runtime Configuration 时：

Host Artifact
    │
    ▼
Runtime Configuration
    │
    └── 解析：
        tasks → 当前上下文对应的 Version 或 URL

Remote 代码之后同样是在 Runtime 加载。真正的差异发生在更早一步：Host 是在 Build 前就知道“要加载谁”，还是 Build 之后才知道。

在一些文章里，“静态微前端”还会被用来指完全在 Build 阶段合并进单一应用的代码。这是另一层分类。本文中的“静态”和“动态”，只讨论 Host 与 Remote 之间的绑定时间点。

静态绑定让系统组合更容易理解

在静态绑定中，Host Artifact 已经知道 Remote 名称、地址，或者固定的解析规则。系统组合因此较早确定。

这可以是 Host Configuration 里直接写完整 URL，也可以只是一个稳定名称，再按照 Artifact 中固定规则转换为地址。关键在于：这些信息在 Host Artifact 被创建时已经确定。

静态绑定最重要的优势，并不是“实现起来比较简单”。

真正的优势是：Runtime 中需要变化和被管理的东西更少。

你不需要额外的 Manifest，因此也不需要处理它的可用性、格式兼容和 Cache 行为；不需要一个 Registry 在 Runtime 决定 Remote Version；产品当前由哪些 Artifact 组成，也可以直接从 Host Artifact 及其配置中理解。

这会减少生产环境中可能出现的组合。如果一个明确的 Host 与三个明确的 Remote 一起通过验收，这个产品状态通常比较容易复现。名称错误、地址错误等问题，在有合适 Validation 的前提下，也更可能在 Build、Integration 或 Release 阶段暴露，而不是第一次出现在用户 Browser 中。

不过这里有一个前提：被引用的 Artifact 必须是 Immutable，或者实际交付的版本必须被记录。一个 URL 看起来稳定，但其内容可以随时被覆盖，并不意味着系统真的可复现。

对于那些本来就有意识地以“产品整体版本”进行发布的系统，这种可预测性可能很有价值。共同版本并不一定是不幸遗留的技术限制，也可以是一项明确受控的产品属性。

静态绑定还可以降低平台开销。如果产品没有真实需求，团队就不必额外维护 Remote Manifest、Release Channel 或按上下文解析版本的基础设施。少一点 Infrastructure 并不等于少一点 Architecture。它也可能意味着：架构只引入产品真正需要的那部分可变性。

当然，限制同样存在。如果 Host 中固定的 Remote 地址发生变化，可能需要重新 Build Host；新增或删除 Remote 名称，也经常需要调整 Host Configuration。如果 Test、Acceptance 和 Production 的地址都不同，要在所有环境使用完全相同的 Host Artifact 也会更困难。

区域或 Tenant 级的映射同样不容易只靠静态绑定表达。例如意大利已经需要 Tasks Remote v2，而德国还应该保持 v1，那么这种差异必须在别的地方表达，或者通过不同 Host Artifact 实现。

但这并不意味着静态 Remote 只能和 Host 一起 Deployment。

如果 Host 知道的是一个稳定地址：

https://tasks.example.com/remote-entry.js

负责这个地址的团队仍然可以独立发布新的 Artifact。只要名称、地址以及 Integration Contract 保持兼容，Host 不需要重新 Build。

所以静态绑定不会自动阻止 Remote 独立 Deployment。

它只是意味着：Host 层面的映射关系不变。

动态绑定把决定推迟到更晚

动态绑定意味着，具体 Remote 映射在 Host Build 结束之后才被决定。Host Artifact 可能仍然知道某个 Remote 的业务角色，但还不知道最终 URL 或 Version。

映射可以来自 Manifest：

{
  "tasks": "https://cdn.example.com/tasks/2.1.0/remote-entry.js",
  "members": "https://cdn.example.com/members/1.7.3/remote-entry.js"
}

也可以由 Registry、Deployment Configuration、Gateway、CDN Rule 或 Tenant Configuration 决定。机制不是重点。重点是：映射可以在不重新生成 Host Artifact 的情况下变化。

这样，同一份 Host Artifact 可以被部署到多个 Environment。Test Environment 指向一组 Remote 地址，Production 指向另一组，而 Host 自身完全相同。新的 Remote Version 可以通过修改映射被激活；Rollback 也可能只需要把映射切回上一版本。

Release Channel 也因此成为可能。Preview 可以加载新版本，而 Stable Channel 继续使用旧 Artifact。不同 User Group、Country 或 Tenant 可以获得不同 Remote Version，而不必为每一种组合单独 Build Host。

一个实际场景可能是：

意大利      → Tasks Remote v2
德国        → Tasks Remote v1
Preview     → Tasks Remote v2

意大利团队已经完成并发布 v2。新版本先在 Preview Channel 中验证，然后只为意大利激活；德国暂时保持 v1。只要映射由 Host Artifact 外部管理，就不需要新的 Host Build。

这种延后绑定最主要的价值，就是允许已经存在的 Capability 在更晚阶段切换到另一个 Version 或地址。

但它不会自动让 Host 支持任意新增 Remote。如果 Host 想在完全不修改自身的情况下发现全新的 Remote，还需要一个通用的 Discovery、Navigation、Authorization 与 Composition Contract。动态 URL 本身不会把普通 Host 变成 Plugin Platform。

这就是动态绑定真正提供的自由：Remote Version 可以更晚、也更细粒度地被激活。

但它不会消除复杂度。它只是把复杂度移动到了别的阶段。

Manifest 自己会成为一个新的 Runtime Dependency。如果 Manifest 不可访问，Host 可能就无法解析 Remote。Manifest 里如果出现错误 Name、无效 URL 或已经不存在的 Version，问题也许直到用户 Browser 中才会暴露。

即使一个组合从技术上能加载，也不代表它在业务或技术上兼容。Host 可能依赖某个 Contract，但旧版 Remote 还没有实现；Remote 可能假设某个 Global State 或 Service 存在，而它只在特定 Host Version 中提供；Shared Library 也可能存在互相不兼容的版本预期。一个格式正确的映射，还远远不等于一套真正能工作的 Integration。

每增加一个可变维度，Test Matrix 都会变大。如果三种 Host Version、四种 Remote Version 和两个 Release Channel 可以自由组合，你获得的首先不是“更多自治”，而是更多可能的系统状态。

动态绑定也要求更好的 Observability。Support 和 Operations 必须能够看到：受影响用户到底加载了哪个 Remote Version。Log 和 Trace 不只要识别 Host，还应该让解析出的 Remote URL、Version 以及加载失败可见。

Cache Behavior 同样会成为架构的一部分。Manifest 也许已经指向新版本，但 CDN Cache 不一定马上同意。Browser、CDN 或 Service Worker 仍然可能提供旧映射；反过来，一个短暂错误也不应该导致原本有效的 Artifact 被不必要地赶出 Cache。

Security 问题也会变得更重要：谁有权改变映射？哪些 Origin 被信任？Tenant 可以加载任何 Registry 中的 Version，还是只能加载明确批准的 Artifact？怎样避免被篡改的 Configuration 向 Host 注入任意代码？

更晚绑定扩大了操作空间，同时也把更多决定与故障推迟到了系统生命周期的更晚阶段。

动态绑定不会消除 Release Coordination

一个常见说法是：Host 和 Remote 绝不能一起 Release，否则就不算“真正的微前端”。

这个观点混淆了两件事：具备独立变化的能力，与强制每一次变化都独立交付。

一个业务扩展完全可能同时影响多个产品区域。新的 Flow 可能需要 Navigation、Task Management 和 Reporting 一起修改。受监管的 Release 也可能要求以完整产品为单位验收。某次 Migration 甚至可能有意原子化激活，以避免旧 Contract 与新 Contract 长时间并存。

Support 和业务团队同样可能需要一个明确可描述的产品状态。在某些环境里，“Host 4.2 加上 Runtime 随机解析到的一组兼容 Remote”并不一定比一个明确批准过的组合更有价值。

所以，共同 Release 并不自动是 Anti-Pattern。

真正的问题是：

这次协调是业务或运行上有意识需要的，还是纯粹被技术耦合强迫出来的？

如果多个应用一起 Release，是因为某个变化本来就要作为一个整体激活，那是一个明确架构决策。反过来，如果 Reporting 里一个很小的局部修复，也因为不稳定 Contract 和隐藏依赖而必须拉动所有 Remote 的 Release Train，那么系统并没有实现真正独立。

动态绑定不会自动解决这个问题。Manifest 确实可以稍后切到新版本，但如果这个新版本只能与一个新 Host 和另外两个新 Remote 一起工作，协调依然存在——只是从 Build 阶段搬到了 Runtime Configuration 管理。

静态和动态的边界，没有看起来那么二元

真实系统很少完全落在两个干净类别中。很多架构在某一层静态，在另一层动态。

静态地址，动态内容

Host 可以长期只认识同一个 URL：

https://tasks.example.com/remote-entry.js

但这个地址背后的实际 Version 仍然可以变化。负责团队可以发布新 Artifact、替换当前交付内容，或者让 Routing 切到另一版本。

对 Host 来说，绑定仍然是静态的。

激活发生在 Host 之外。

这种方式有时已经足以提供所需独立性。Host 不需要 Manifest 或 Registry，而 Remote Team 仍然可以在稳定地址背后独立 Release。

当然，地址背后的切换仍然必须可控。Rollback、Cache Invalidation 以及实际交付版本的可追踪性依然是运行责任。

静态地址，动态 Routing

稳定地址还可以指向 Gateway 或 CDN：

Host
  │
  ▼
https://remotes.example.com/tasks
  │
  ├── 意大利 → v2
  ├── 德国   → v1
  └── Preview → v2

Host 仍然只知道固定入口。最终交付哪一个 Version，则由 Infrastructure 根据 Region、Header、Cookie、Tenant 或 Release Channel 决定。

这样，动态性不在 Frontend，而在 Routing。

从业务决策角度看，本质并没有变：Remote 映射仍然是在 Host Build 之后改变。技术上，这种移动可能非常合理——如果 Gateway 或 CDN 本来就已经拥有成熟的 Release、Rollback 和区域交付能力。

动态 Manifest，但组织上仍然固定 Release

反过来也完全可能。Host Runtime 从 Manifest 读取地址，但 Manifest 只有在一次共同、受控的产品 Release 中才会修改。

技术上是动态绑定。

组织上却接近静态运营。

这不一定是错误。也许 Manifest 的作用只是让同一 Host Artifact 能部署到多个 Environment，而 Production 仍然有意识地共同 Release。拥有独立激活能力，并不意味着组织必须每次都使用它。

同一个 Host 中可以采用不同策略

所有 Remote 也不必遵循同一种绑定方式：

Host
├── 核心流程      静态绑定
├── 主数据        静态绑定
├── Reporting     动态绑定
└── 国家功能      按 Region 动态绑定

核心流程和主数据也许只会与产品整体一起变化，并且应该始终形成一个清晰可复现的组合。Reporting 可能拥有自己的 Release Rhythm。国家功能则需要按区域批准状态解析。

如果硬要用一套全球统一的 Federation Strategy，反而是在把不同需求强行抹平。

合理的绑定时间点完全可以按 Remote 不同。

动态绑定并不等于组织自治

动态绑定可以支持独立激活。

但它不会自动创造自治团队。

如果 Remote Contract 不稳定、依赖 Global Store，或者只能与某个特定 Host Version 一起工作，它依然高度耦合。多个 Remote 如果必须同步更新，Registry 也救不了你。每个 URL 可以单独修改，并不意味着每次变化都能单独负责。

如果每次 Manifest 变化都必须由中央 Platform Team 手工协调，也同样没有真实自治。技术决策虽然被推迟了，但组织决策权并没有分布出去。

反过来，静态绑定也完全可以提供足够自治。只要 Remote 地址稳定，负责团队就可以在它背后独立 Deployment。只要 Integration Contract 保持兼容，正常 Remote Release 不需要新的 Host Build，就已经获得了很有价值的独立可变更性。

因此，技术分类不能直接等同于组织结果。

重要的不只是“Remote 映射什么时候可以改”，还包括谁可以改、必须遵守哪些 Contract，以及团队能否独立承担改动后果。

什么时候静态绑定已经足够？

当产品拓扑本身稳定时，静态绑定通常很合理。如果 Host 数量少、产品区域长期固定，就没有必要只因为技术做得到，就把这些映射全部变成 Runtime 可变。

稳定 Remote URL 也是支持早绑定的重要理由。如果一个团队可以在固定地址背后独立 Deployment，而 Host 无需调整，那么目标自治已经实现了很大一部分。

静态绑定也适合那些有意识以受控产品版本进行 Release 的系统。原因可能来自业务、监管或运行。此时 Reproducibility 不是 Monolith 时代遗留下来的麻烦，而是产品属性。

如果小 Test Matrix 和容易理解的系统组合，比最大激活自由更重要，静态绑定同样很合适。当所有 Production Environment 本来就永远使用同一组 Remote 和同一组地址时，额外 Runtime Manifest 很难创造价值。

常见信号包括：

• Remote Topology 很少变化。
• 地址长期稳定。
• 没有 Region 或 Tenant 级的 Version 差异。
• 正常 Remote Release 本来就不需要 Host Build。
• 共同 Release 是业务上有意识的选择。
• Runtime Manifest 并不会解决任何真实 Release Bottleneck。

静态绑定不是走向“真正微前端”的原始过渡阶段。

它完全可能就是业务、技术和经济上都最合适的答案。

什么时候动态绑定值得？

当 Remote 映射真的必须在 Host Build 之后变化时，动态绑定才有明确理由。

最清晰的场景之一是：同一 Host Artifact 要原封不动部署到多个 Environment，但各环境 Remote URL 不同。此时 Host 启动时读取映射，比每个环境单独 Build Host 更合理。

独立 Activation 和 Rollback 也可能创造真实价值。Remote Team 发布新版本，先进入 Preview Channel，再逐步为特定 User Group 开启；如果出现问题，可以直接把映射切回旧版本，而不需要重新发布 Host。

其他合理需求包括：Country/Tenant 并行版本、Optional Capability，以及明确作为可变产品平台设计的 Host。不过，要在完全不改 Host 的情况下加入一个全新 Remote，Host 仍然需要通用 Discovery、Routing 和 Integration Contract。动态地址本身不会把 Host 变成 Plugin Platform。

以下 Bottleneck 真实存在时，动态绑定尤其值得考虑：

• 同一 Host Artifact 必须服务多个 Environment。
• Remote Version 需要独立 Activation 和 Rollback。
• 需要 Preview、Canary 或 Stable Channel。
• Country、Tenant 或 User Group 使用不同 Release 状态。
• 多个 Remote Version 必须并行存在。
• Host 明确作为 Platform，并通过通用 Contract 发现新的 Remote。
• Infrastructure Routing 需要决定实际交付版本。

但“技术上可以”仍然不是充分理由。

组织还必须能够运营这些额外 Runtime Contract、故障模式和版本组合。这意味着可靠 Activation Process、清晰 Compatibility Rule、有意义的 Telemetry，以及对错误映射明确的责任。

要求独立激活，就必须同时支持独立撤回、独立诊断和独立 Support。

经济价值来自被消除的 Bottleneck

这个决定同样有一个经常在纯技术讨论中被忽略的经济面。

静态绑定可以省钱。它需要更少的平台组件，可以限制同时支持的组合数量，从而缩小 Test Matrix，也更容易 Debug。产品状态更容易复现，也不需要额外运营一个动态解析层。当然，Remote Loading Error 和实际交付 Artifact 仍然应该可观察。

这些节省并不特别戏剧化，但会持续发生：更少 Infrastructure、更少 Operations Logic、更少组合、更少需要跨团队长期维护的知识。

动态绑定也可能创造很大的经济价值。更快 Rollback 可以减少 Downtime；区域 Release 可以分阶段进入市场；不同 Release Rhythm 能避免一个高频变化区域长期等待整个系统最慢部分；同一个 Host Artifact 服务多个 Environment，也可以降低 Build 和审批成本。

但这些价值只有在能力被真正使用时才存在。

如果某个 Remote 的映射在 Host Build 之后从来没有变过，那么 Runtime Manifest 并不是自治投资。

它只是额外 Infrastructure：需要加载、Version、保护、Monitoring 和理解。

所以经济上的核心问题是：

延后绑定到底消除了哪个具体 Bottleneck？

如果没人能给出可靠答案，那么“更多动态”首先就只是“更多系统”。

技术实现本身其实很小

静态绑定的技术原则可以被极度简化成：

const remotes = {
  tasks: 'https://tasks.example.com/remote-entry.js',
  members: 'https://members.example.com/remote-entry.js',
};

映射属于 Host Configuration 或最终生成的 Artifact。

动态绑定则稍后解析：

const remotes = await fetch('/remote-manifest.json').then((response) => response.json());

之后到底用 Module Federation、Native Federation、Import Maps、Web Components 还是自定义 Runtime Mechanism 加载这些地址，并不会改变这个战略决策。服务端 Configuration、Registry 或 Gateway 同样可以完成解析。

具体 Implementation 可以替换。

绑定时间点以及它带来的后果不会因此改变。

如果使用 Nx，应当以当前官方 Nx Module Federation 文档作为起点。具体 Generator、Bundler Integration 和 API 都依赖 Nx 与 Framework Version。也正因为这些细节不断变化，根据旧示例长期维护一套自定义特殊配置，并不是一个好的出发点。

最晚的“有用绑定”

动态绑定并不是一种更高级、更“成熟”的微前端形态。

它只是把 Remote 映射决策推迟到了更晚阶段，同时也接手了更多 Runtime Variant 的责任。

正确的绑定时间点，不是技术上能做到的最晚时间。

而是仍然存在明确业务或运行收益的最晚时间。