Host 应该加载哪个 Remote 版本？

Remote A 1.0.0 已发布。
Remote A 1.1.0 已发布。

Host 应该加载哪一个？

最直接的答案通常是：加载配置里指向的那个地址。

Host 配置
└── Remote A → /remote-a/1.0.0/remoteEntry.js

如果之后要切换到 1.1.0，就修改映射：

Host 配置
└── Remote A → /remote-a/1.1.0/remoteEntry.js

如果这个地址已经被编进 Host Artifact，那么切换版本就需要新的 Host Build 和一次新的 Host 发布。Remote 虽然已经可以独立发布，但在这个模型里还不能独立激活。

另一种模型把具体版本映射移出 Host Bundle：

Host
└── 在 Runtime 解析一组已批准 Product Composition
    └── Remote A → Version 1.1.0

此时，只要新 Remote Version 已知且兼容，切换它就不需要新的 Host Code Release。取而代之的是激活一组新的 Product Composition。

但这不意味着 Release Decision 消失了。激活新的 Product Composition 本身就是一次受控的 Release Decision。

关键区别在于 Publish 与 Activate：Remote Team 发布一个不可变 Artifact；独立的批准与激活决策才决定，这个 Artifact 在什么使用上下文里真正成为产品的一部分。

因此 Host 不应该自动加载“最新版本”。它应该解析一个明确批准、可以复现的 Product Composition。

独立发布的是各个 Remote。真正被激活的是一组 Product Composition。

什么时候切换版本需要 Host Release

从 Remote A 1.0.0 切换到 1.1.0 是否需要 Host Release，并不只取决于 Remote 是否动态加载。真正决定因素是：具体版本映射存在哪里。

如果 Remote 地址静态嵌在 Host Artifact 中：

Host-Build
└── Remote A → Version 1.0.0

切换到 1.1.0 就改变了 Host 本身。即使 Remote Artifact 已经可访问，也必须重新 Build Host，或者至少带着修改后的配置重新发布。

如果 Product Composition 在外部解析，Host Code 可以保持不变：

Host
└── 加载 Composition ID
    └── Remote A → Version 1.1.0

Host 只需要具备解析 Product Composition 并加载其 Artifact 的能力。1.0.0 到 1.1.0 的切换，通过激活另一个 Composition ID 完成。

没有 Host Code Release，并不等于没有控制。Product Activation 不是用任意性替代 Host Release，而是建立了一个独立、显式的批准层。

如果第一次把全新 Remote 加入产品结构、Mount Contract 改变，或者新的 Route/Layout Area 只能通过 Host 定义，那么 Host Release 依然可能必要。同样，如果 Host 必须理解新的 Composition Manifest Schema、Shared Runtime Dependency 出现不兼容变化，或者 Remote 依赖旧 Host 没有提供的新能力，也需要 Host 升级。

External Activation 解耦的是兼容版本之间的切换，不会神奇地解除 Host 与 Remote 的 Integration Contract。

已发布，不等于已激活

一个可靠的 Activation Model 首先需要把这些概念分开：

Build
→ 生成 Artifact

Publish
→ 把 Artifact 放到唯一地址

Approval
→ 确认它适用于某个定义好的 Context

Activation
→ 把已批准 Product Composition 分配给 Channel 或使用上下文

Resolution
→ 向 Host 返回当前 Active Product Composition

Load
→ 加载其中引用的 Remote Artifact

Build 与 Publish 属于 Remote Lifecycle。Approval 与 Activation 属于 Product Composition Lifecycle。Host 负责执行已经激活的映射。

这不仅是语言上的精确。如果不区分，技术交付、产品批准和真正生效的产品变化都会混成一个模糊的“Deployment”。最后没人能明确知道究竟发生了哪一步。

Publish 只表示 Remote Artifact 可以被获取，不代表它已经适用于 Production、某个 Market、某个 Tenant 或 Pilot Group。

Approval 确认它适用于定义好的 Context。Activation 才让这组已经批准的 Product Composition 在该 Context 中真正生效。

Publish 不等于 Activate。

Host 不应该通过越来越多的国家、Tenant 或 Channel 分支来自己决定批准政策。它应该可复现地执行已经做出的决策。

Publish、Approval、Activation 与 Load 是不同步骤。

使用不可变 Artifact，而不是 `latest`

为了以后能重建 Product Composition，其中的组成部分必须保持唯一可识别。

最简单的模型是：

/remote-a/1.0.0/remoteEntry.js
/remote-a/1.1.0/remoteEntry.js

1.1.0 发布后，1.0.0 仍然保持原样可用。如果需要修复 1.1.0，也不要覆盖它，而是生成新的 Artifact：

/remote-a/1.1.1/remoteEntry.js

一个已经发布的地址之后不应该指向不同内容。否则保存下来的 URL 无法证明过去某一时刻真正交付的是哪些 Bytes。

因此 latest 不是可复现的 Production Reference。它不是稳定 Artifact State，而是一条会变化的 Selection Rule。同一个地址在两个时间点可以返回不同内容。

Semantic Version 对沟通与 Compatibility Statement 很有帮助，但对严格 Artifact Identification 不一定够。还可以保存 Build ID、Commit ID 或 Artifact Digest。关键是能够唯一识别真正被交付的内容。

可变的不是 Artifact，而是 Artifact 与使用上下文之间的映射。

production-de
之前    → Remote A 1.0.0
之后    → Remote A 1.1.0
Rollback → Remote A 1.0.0

Promotion 应该推动同一个已经测试过的 Artifact，而不是重新 Build 一个“理论上相同”的版本。

三个不同的 Metadata 层次

一个稳健 Activation Model 可以区分三种 Metadata：Artifact Manifest、Composition Manifest 与 Activation Mapping。它们不是必须使用的具体技术标准，而是帮助显式责任的参考模型。

Artifact Manifest

Artifact Manifest 描述一个具体发布的 Remote Artifact。

{
  "name": "remote-a",
  "version": "1.1.0",
  "buildId": "184",
  "entry": "https://cdn.example.com/remote-a/1.1.0/remoteEntry.js",
  "integrity": "sha384-..."
}

还可以包含 exposed module、additional asset 或 expected dependency 等技术信息。

但它不回答这个 Remote 是否允许进入 Production，也不知道某个 Market 或 Pilot Group 是否已经批准。

Artifact Manifest 只描述 Artifact，不做 Product Approval。

不可变 Composition Manifest

Composition Manifest 描述一组未来仍能重建的、已经批准的 Remote Artifact，以及适用的 Host Context。

{
  "schemaVersion": 1,
  "compositionId": "composition-2026-08-06-184",
  "expectedHostVersion": "5.4.2",
  "remotes": {
    "remoteA": {
      "version": "1.1.0",
      "buildId": "184",
      "entry": "https://cdn.example.com/remote-a/1.1.0/remoteEntry.js",
      "integrity": "sha384-..."
    },
    "remoteB": {
      "version": "2.3.1",
      "buildId": "92",
      "entry": "https://cdn.example.com/remote-b/2.3.1/remoteEntry.js",
      "integrity": "sha384-..."
    }
  }
}

一旦发布，这个 Manifest 不再修改。不同的 Host/Remote 组合得到新的 Composition ID。

这里的 Host Version 还需要一个边界说明：已经交付的 Host 即使加载新的 Composition Manifest，也不能靠它“反向替换自己”。在这个模型中，Expected Host Version 是 Compatibility Condition 与诊断信息。如果 Host Artifact 自己也要和 Remote 一起被激活，那么更外层的 Bootstrap/Delivery Layer 必须同样绑定到 Composition ID。

Product Composition 是一个不可变 Snapshot。它不仅列出各个 Remote Version，也明确记录哪一组组合被批准，以及适用于哪个 Host Context。

Activation Mapping

Activation Mapping 把一个 Channel 或 Usage Context 指向某个已经批准的 Composition ID。

例如，它可以作为独立配置明确保存不同 Context 的 Composition：

{
  "production-de": "composition-2026-08-06-171",
  "pilot-de": "composition-2026-08-06-184",
  "validation": "composition-2026-08-06-184"
}

也可以简化表示为：

production-de
└── Composition 171

如果希望 Remote A 1.1.0 对 production-de 生效，不去修改旧 Composition Manifest，而是发布新的不可变 Composition，然后原子地切换 Channel Pointer。

不可变的是 Artifact 与 Composition Snapshot。真正可变的只有使用上下文到已批准 Snapshot 的受控映射。

不可变 Composition 与可变 Channel Activation 是不同层次。

为什么激活的是完整 Product Composition

技术上当然可以为每个 Remote 单独维护一个可变 Production Pointer：

remoteA-pointer 被修改
remoteB-pointer 暂时保持旧值
remoteC-pointer 稍后再修改

但这样会产生中间状态。用户可能拿到一组从未一起测试、从未明确批准过的版本组合。多个 Pointer 又可能通过不同系统、Cache Node 与更新路径传播，问题会更明显。

不可变 Composition Snapshot 避免了这些过渡组合：

Composition 171
├── expected Host 5.4.2
├── Remote A 1.0.0
├── Remote B 2.3.1
└── Remote C 4.0.2

Composition 184
├── expected Host 5.4.2
├── Remote A 1.1.0
├── Remote B 2.3.1
└── Remote C 4.0.2

Activation 只改变映射：

production-de
从 Composition 171
到 Composition 184

因此最小受控激活单位不一定是单个 Remote。为了 Reproducibility 与 Auditability，完整 Product Composition 往往才是更重要的单位。

这不代表每次 Remote Release 都要重建其他 Remote。已经存在的 Artifact 只是被新的 Composition Snapshot 再次引用。

系统也不需要支持所有已发布 Version 的任意组合。真正受支持、被批准的是具体 Product Composition。这样才能限制组合爆炸。

Host 负责解析，不负责做批准决策

External Version Resolution 只有在 Approval Policy 没有转而被写进 Shell Code 时，才是真正解耦。

一个不好的模型是：

if (country === 'DE' && tenant === 'pilot') {
  loadRemoteA('1.1.0');
} else if (country === 'US') {
  loadRemoteA('1.0.0');
}

这样 Host 就拥有了 Country、Tenant 与 Approval Logic。新 Activation Rule 又可能要求 Host Release，也更难追溯谁在什么时候、为什么激活了哪个版本。

目标模型把决策和技术执行分开：

Usage Context
        ↓
Activation Control
        ↓
Composition ID
        ↓
Host 精确加载被引用 Artifact

Host 知道如何解析和加载。Approval 与 Activation Decision 则不属于 Host Application Code。

实现方式可以是 External Activation Manifest、Configuration Service、Server-side Resolution 或 Edge Configuration。大型系统也可能形成单独 Activation Control Plane。名字听起来很重，但最简单情况下它只是受控管理一条 Mapping，完全可以落在一张小型 Database Table 或 Configuration Service 里，不需要因此建一个庞大中央 Microservice。

Host 不应该实现 Approval Policy。它应该可靠地执行 Approval Policy 的结果。

Release Channel 与 Usage Context

Release Channel 不等于技术 Environment。

Environment 可能是 development、test、production，通常表示独立基础设施和运维区域。

Release Channel 则表达 Approval Status 或期望使用上下文：

validation
internal
pilot
production
restricted-production

Channel 不一定需要自己的基础设施：

validation
└── Composition 184

pilot-de
└── Composition 184

production-de
└── Composition 171

同一个不可变 Artifact 可以逐步在多个 Channel 中 Promotion。Promotion 不重新 Build Remote，只是扩大同一个已测试 Artifact 被批准使用的 Context。

Activation Context 还可以包括：

Activation Context
├── Environment
├── Release Channel
├── Market / Regulatory Region
├── Tenant
├── Product Variant
├── User Group
└── Stable Rollout Cohort

不是每个产品都需要所有维度。每增加一个维度，Active Product State 的数量以及 Governance、Support、Observability 成本都会增加。

细粒度 Activation Model 不是目的本身。只区分真实 Approval Decision 所需要的 Context。

Deterministic Mapping 与固定 Session

Dynamic Resolution 不应该被理解成随机、不断变化的 Composition。

一个 User 或 Tenant 不应该在每次页面访问时无规则地拿到不同 Product Composition。Percentage Rollout 也应该使用稳定 Cohort：

User / Tenant
        ↓
Stable Cohort
        ↓
Composition ID

更重要的是单次 Page Load 或 Session 内的稳定性。Host 应该在 Bootstrap 时解析一个 Composition ID，并让之后所有 Lazy-loaded Remote 都使用这个 Snapshot。

否则可能出现：

Remote A 从 Composition 171 加载
        ↓
Channel Mapping 发生变化
        ↓
Remote B 后来从 Composition 184 加载

正在运行的应用就会混合两个从未一起验证过的产品状态。

Dynamic Activation 不意味着 Runtime Session 应该随意切换 Composition。新的 Activation 可以在新的 Session 或受控 Reload 后生效。

Pin Composition ID 也明显改善 Diagnosis：错误可以明确归属到 Session 开始时解析出的 Product State。

受控批准与 Auditability

在受监管或强控制系统中，仅仅知道“现在活动 URL 是什么”还不够。必须能够重建有效 Product State 是如何形成的。

常见审计问题包括：

发布的是哪个 Remote Artifact？
它对应哪个 Version、Build ID 与 Digest？
哪个 Product Composition 被批准？
Approval 对哪个 Channel、Market 或 Tenant 有效？
哪些 Check 已完成？
谁批准 Activation？
谁技术执行 Activation？
什么时候生效？
之前的 Composition ID 是什么？
某个历史时间点到底激活了哪个 Product Composition？
Rollback 在什么时候、因为什么发生？

Activation Record 可以包含：

Activation Record
├── Composition ID
├── Host Version
├── Remote Versions and Digests
├── Target Channel
├── Usage Context
├── Approval Decision
├── Timestamp
├── Executing Identity
└── Previous Composition ID

并不是所有信息都必须暴露在公开 Composition Manifest 中。

可以明确区分 Data Plane 与 Control Plane：

Data Plane
└── 向 Host 提供运行所需 Product Composition

Control Plane
└── 管理 Approval、Activation、Role 与 Audit Trail

Host 需要 Product Composition。组织还需要证明这组 Composition 是如何产生的。

根据 Risk Model，职责分离、Four-eyes Approval 或防篡改 Audit Log 可能很合理，但它们不是每个系统的通用法律要求。

受控 Activation 与 Remote 自主发布并不冲突

受控 Product Activation 不会取消 Remote 的独立开发与发布。

Remote Team
├── 开发
├── 测试
├── 版本化
└── 发布 Remote A 1.1.0

Approval Process
└── 确认它适用于定义好的 Channel

Activation Control
└── 把 Composition 184 分配给 Pilot Channel

Host
└── 加载 Composition 184

Independent Deployment 不等于 Uncontrolled Activation。

Remote Team 不必等待 Host Build 才能让兼容版本技术上可用。组织仍然可以决定何时、对谁让它成为产品的一部分。

也就是说，两个问题被分开了：Remote Artifact 是否已经可用？它应该在哪个 Product Context 中生效？

并行版本与它们的 Support 成本

Activation Control 可以让多个 Version 同时有效：

Remote A
├── 1.1.0 for validation
├── 1.1.0 for pilot-de
├── 1.0.0 for production-de
└── 0.9.4 for a temporary legacy tenant

这对于 Pilot Group、Market-specific Approval、不同 Rollout Timing、Controlled Rollout 或临时 Compatibility Window 很有用。

但 Parallel Version 不是免费的长期状态。

每增加一个 Active Version，Support Matrix 与可观察 Product Combination 都会增长。API 要更久保持 Backward Compatibility。Error 可能只存在于特定 Context。Diagnosis、Monitoring 与 Sunset 都会更复杂。

每一个仍然 Active 的旧版本都应该能回答：

为什么还 Active？
对谁 Active？
谁负责它？
哪些 API 必须继续支持它？
什么时候结束？
当前什么条件阻止 Promotion？

Parallel Version 需要 Owner 和 Expiry Date。

它是受控 Release Tool，不是长期任意组合版本的邀请。

有限 Version Skew 下的兼容性

Dynamic Activation 可以引用一个 Version，但不会自动让这组 Version 兼容。

需要考虑至少：

Host 与 Remote 的 Mount Contract；
当前 Host Version；
API 与 Data Model；
Shared Runtime Dependency；
所需 Browser / Platform Capability；
Product Composition 中其他组成部分。

Manifest 可以引用 Version，但不能独自保证 Technical / Business Compatibility。

因此 Product Composition 的 Approval 可能需要 Automated Check，以及根据 Risk Model 决定是否需要 Manual Check。

并不是所有理论上可能的组合都需要支持，只支持真正被批准的 Product Composition。

这样 Version Skew 才保持有界。Remote 可以相对于 Host 或其他 Remote 以不同 Version 运行，但只在定义好的 Compatibility Window 中。

Atomic Activation

切换到新的 Composition ID 应该被视为一个原子决策。

有问题的是只显示 Product Composition 的一部分，或者逐个修改 Remote Pointer。分布式 Cache 中不同 Client 暂时一个拿到 Composition 171、另一个拿到 Composition 184 可以接受，只要两个 Snapshot 都完整、已批准并内部一致。

一个可能流程是：

创建新的不可变 Product Composition。
验证 Schema、Artifact Source 与 Reference。
完成 Approval。
原子更新 Channel → Composition ID Mapping。
记录 Audit Trail。
观察激活后的 Product State。

这不是分布式事务意义上的“全世界同一毫秒切换”。真正要求的是：每个解析结果都指向一个完整 Snapshot，而不是临时拼接状态。

Cache、故障与 Last Known Good

动态 Activation Service 会进入应用启动关键路径，因此必须有明确 Cache 与 Failure Model。

如果每次启动都必须实时访问一个无法缓存的中央服务，那么 Activation Control 本身就成为新的 Single Point of Failure。

更稳健的模型通常允许缓存不可变 Composition Manifest，并把易变部分限制在很小的 Channel Mapping 上。

例如：

Channel Mapping
production-de → Composition 184

Composition 184
└── immutable, cacheable

如果 Mapping Resolution 临时失败，可以根据产品 Risk Model 考虑 Last Known Good。

但这个选择必须明确回答：

Last Known Good 保存在哪里？
首次访问、没有 Cache 时怎么办？
Manifest 语法合法但不完整怎么办？
Activation 多快对 Client 可见？
Rollback 多快可见？
Cache TTL 如何限制响应速度？
Older Artifact 是否仍然可获取？

进入 Critical Startup Path 的 Activation Service 必须拥有刻意设计的 Failure Model。

Integrity 与 Activation Control 的保护

Dynamic Manifest 并不会自动比 Static Mapping 更安全。它提升可控性，但自身也成为 Availability 与 Security Boundary。

Activation Control 不能变成 Host 可以借此加载任意 Remote Source 的机制。

为什么浏览器能够信任动态选择的 Remote Artifact？这个问题可以拆成四层：

选择 Version
        ≠
验证 Bytes
        ≠
信任 Source
        ≠
授权 Activation

Activation 决定在当前 Usage Context 加载哪个 Artifact。Integrity 检查实际下载的 Bytes 是否与预期 Artifact 一致。Provenance/Trust 关注 Artifact 是否来自真正可信的 Source 与 Publish Process。Activation Authorization 则是组织问题：谁有权修改 Mapping？

这四层可以技术上用不同机制实现，但不应该混淆。

可能的保护措施包括：

仅允许可信 Artifact Source；
Encrypted Transport；
Schema Validation；
唯一 Artifact Digest；
Integrity Metadata；
如果 Risk Model 要求，对 Manifest 或 Product Composition 签名；
限制 Activation Mapping 的写权限；
可追溯的 Approval / Activation Identity；
阻止加载未批准 Source。

Integrity 不等于 Approval，也不等于 Trust。

Hash / Digest 可以证明加载 Bytes 与预期 Artifact 一致。Subresource Integrity 为 script 与 link Element 提供 integrity 机制。¹ 但这不会自动证明 Artifact 已经业务批准、Source 值得信任，或者它所在的 Composition 被授权激活。具体动态 Loader——例如 Module Federation 内部的 import()——是否可以使用同样机制，需要根据实际 Integration 单独验证。

Content Security Policy 可以通过 script-src 限定允许的 Origin，也可以通过 Hash 或 Nonce Source 允许具体 Script Instance。² 但单纯 Origin Allowlist 不能回答同一 Origin 下某个具体版本是否已经批准。CSP 因此不会自动解决 Dynamic Remote 的 Trust Problem；仍然需要明确 Release Process 与适合的完整性机制。

通过撤回 Mapping 完成 Rollback

有不可变 Artifact 与 Composition Snapshot 后，Rollback 不需要重新 Build 旧版本。

Artifact Store
├── Remote A 1.0.0
└── Remote A 1.1.0

Activation 前：

production-de → Composition 171
               └── Remote A 1.0.0

Activation 后：

production-de → Composition 184
               └── Remote A 1.1.0

Rollback：

production-de → Composition 171

Remote A 1.0.0 与 Host 都无需重新 Build。

Technical Rollback 本质是修改 Activation Mapping：撤回前一次 Activation Decision，把 Channel 指回一个仍然有效的旧 Composition Snapshot。

Atomic Activation 与 Last Known Good。

为什么 Rollback 仍然可能失败

不可变 Artifact 让快速 Rollback 成为可能，但不保证 Rollback 一定安全。

回到旧 Product Composition 的前提是旧 Remote Artifact 仍然存在，并且它的 Dependency / Integration Contract 仍然有效。

Rollback 可能失败，例如：

旧 Artifact 或依赖 Asset 已删除；
API 已经不再 Backward Compatible；
Data Model 或 Server-side State 出现不兼容变化；
当前 Host 已经无法 Mount 旧 Remote；
Shared Runtime Dependency 不再兼容；
Cache Strategy 让 Rollback Mapping 无法及时传播。

一个 Rollback 可以几秒钟就完成技术操作，但业务上仍然不可能。

不可变 Artifact 是快速 Rollback 的必要条件，不是 Backward-compatible Contract 的替代品。

因此，旧 Composition ID 不能因为“还存着”就自动被视为安全 Fallback。它必须在计划中的 Rollback Window 内继续保持技术与业务有效性。

Product Composition 必须可观察、可重建

动态解析的 Product Composition 必须能够被诊断。

至少应该能知道：

Composition ID
Host Version
Remote A 1.1.0 / Build 184
Remote B 2.3.1 / Build 92
Release Channel
Relevant Usage Context
Resolution Timestamp

这些信息可以出现在 Technical Log、Error Report、Support Information、Telemetry、Incident Data 或 Diagnosis View 中。

如果系统并行运行多个 Product Composition，发生错误时必须能说清楚具体哪一组受到影响。

只输出 production 或 latest 不够，因为它们只是可变 Pointer，不是实际加载的 Product State。

要在以后重建过去状态，就必须同时保存当时的 Channel Mapping、引用的不可变 Composition Manifest，以及其中提到的 Remote Artifact。

Feature Flag 是另一层控制

Version Activation 与 Feature Flag 解决的是不同问题。

Version Activation
→ 加载哪个 Remote Implementation？

Feature Flag
→ 已加载 Implementation 内部哪个 Behavior 生效？

某个 Context 可以加载 Remote A 1.1.0，但仍关闭其中的新 Feature：

production-de
└── loads Remote A 1.1.0
    └── Feature Flag disables Feature X

这与继续加载 Remote A 1.0.0 完全不同：

production-de
└── loads Remote A 1.0.0 instead of 1.1.0

Feature Flag 不能替代受控 Artifact Activation。Composition Manifest 也不能替代业务 Feature Flag。

两者可以同时使用，但应该能够独立观察、独立负责、独立回退。

所以 Host 到底加载哪个版本？

Remote Team 可以独立发布 1.0.0 和 1.1.0。Host 何时加载 1.1.0，取决于 Product Context → Remote Version Mapping 管理在哪里。

如果 Remote 地址固定写进 Host Bundle，切换 Version 就需要 Host Release。

如果 Host 解析一个外部、已批准的 Product Composition，那么兼容 Remote Version 可以不经过新的 Host Code Release 被激活。但 Activation 仍然是受控 Product Release。

对于要求可复现、强控制的产品环境，更稳健的模型是发布不可变 Remote Artifact 和不可变 Composition Snapshot，只受控修改 Release Channel → Composition ID 的映射。

Host 在整个 Session 中应该使用同一个 Composition ID。这样之后 Lazy-loaded Remote 也来自同一个批准过的 Product State。

Parallel Remote Version 仍然可以存在，但需要有限 Compatibility Window、明确 Ownership 和计划好的 Sunset Date。

快速 Technical Rollback 只有在旧 Artifact 仍然与 API、Data Model、Host 和 Runtime Contract 兼容时才是业务上安全的。Rollback 是把 Activation Mapping 指回一个更早但仍然有效的 Snapshot。

Publish 不等于 Activate。Independent Remote Release 与 Controlled Product Activation 并不冲突。Host 不应该用 Country/Tenant 分支实现 Approval Policy。真正被激活的是具体 Product Composition，而不是抽象的 latest。

因此 Dynamic Resolution 不只是“一个会变化的 Manifest”。它还需要 Atomic Mapping、明确 Cache Strategy、Integrity Check、Observability、Audit Trail 与刻意设计的 Failure Model。

Host 不加载“最新 Remote”。它加载的是在当前使用上下文中被明确批准的那个版本。

W3C, Subresource Integrity —— 为 script 和 link Element 定义 integrity；Dynamic ES Module Import 不属于该规范。 ↩
W3C, Content Security Policy Level 3 —— script-src 支持 Origin、Hash 与 Nonce Source。 ↩