Webpack 5 的发布带来了很多变化，其中模块联邦（Module Federation）和若干安全相关改进最值得关注。Secure Universe 这个说法并不是官方术语，而是社区里对“把多个前端应用安全地组合成一个可协作整体”的形象化描述。所谓获得宇宙，更多是指通过工程化手段让不同团队、不同技术栈的应用能够在一个统一的安全边界内共享模块与能力。下面先把概念拆开，再从配置、原理和落地实践几个角度展开。
Secure Universe 并不是一个可以一键开启的配置项
很多资料会把 Secure Universe 描述得像一个具体特性，实际上 Webpack 5 的官方文档里并没有这个开关。它更像是一种架构目标：多个远程应用通过 ModuleFederationPlugin 暴露和消费模块，同时依赖 Webpack 5 的输出安全机制来保证运行时不轻易受到恶意脚本或异常依赖的影响。因此，获得宇宙的过程由多个配置项共同完成，而不是找到一个 secureUniverse: true 就能解决问题。
从工程角度看，这个概念至少涉及三个层面。第一是模块解析的严格性，例如启用 deterministic 模块 ID 让缓存更稳定，也避免模块 ID 被猜测；第二是输出内容的安全性，比如 output.trustedTypes 配合可信类型 API 降低 DOM XSS 风险；第三是远程模块的边界控制，包括远程入口地址校验、共享依赖版本强约束等。理解这三层关系，是落地安全宇宙的前提。
输出安全机制：Trusted Types 与哈希策略
Webpack 5 在输出阶段提供了 output.trustedTypes 选项。启用了这个选项后，Webpack 会按照 Trusted Types 规范包装动态创建的脚本，避免直接向 DOM 中插入不可信字符串。默认情况下它不会改变业务逻辑，但浏览器会阻止绕过可信类型策略的脚本执行。这意味着如果你的远程模块中存在拼接 HTML 或 script 注入的行为，会更快暴露问题。
另一项容易被忽略的安全增强是 output.hashFunction。Webpack 5 允许把哈希算法从默认的 md4 切换为更安全的 sha256，还能通过 output.hashDigest 控制摘要长度。这对使用 CSP 或需要审计构建产物的团队很有帮助。下面是一个基础配置示例：
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
mode: 'production',
output: {
publicPath: 'auto',
trustedTypes: true,
hashFunction: 'sha256',
hashDigest: 'hex'
},
optimization: {
moduleIds: 'deterministic',
chunkIds: 'deterministic'
},
plugins: [
new ModuleFederationPlugin({
name: 'host',
remotes: {
app1: 'app1@https://cdn.ipipp.com/app1/remoteEntry.js'
},
shared: {
react: { singleton: true, requiredVersion: '^18.0.0' },
'react-dom': { singleton: true, requiredVersion: '^18.0.0' }
}
})
]
};
上述配置中，publicPath 设为 auto 可以让子应用在动态加载资源时自动解析正确路径，降低被劫持的风险。trustedTypes: true 要求浏览器在创建脚本元素时使用默认策略；如果业务代码里大量使用 eval，需要提前调整，否则会直接报错。hashFunction 改为 sha256 后，文件名中的 hash 更难被碰撞，也更符合安全审计要求。moduleIds 和 chunkIds 设置为 deterministic 则保证构建产物在不同机器上一致，方便对比和缓存。
用模块联邦获得宇宙：远程模块的安全加载
模块联邦让我们可以像 import 本地模块一样加载远程应用暴露的组件，但这同时也带来了新的安全面。远程入口 remoteEntry.js 会在运行时被加载并执行，如果这个地址被篡改或指向了不可信服务器，宿主应用就可能执行任意脚本。因此，获得宇宙的关键一步是限制远程入口的来源，并在生产环境强制使用 HTTPS。
可以在远程地址加载前增加校验逻辑。具体做法是封装一个远程加载器，对环境变量和远程地址做白名单判断。例如：
const allowedRemotes = new Set([
'https://app1.cdn.ipipp.com/remoteEntry.js',
'https://app2.cdn.ipipp.com/remoteEntry.js'
]);
function loadRemoteEntry(url) {
if (process.env.NODE_ENV === 'production' && !url.startsWith('https://')) {
throw new Error('生产环境远程模块必须使用 HTTPS');
}
if (process.env.NODE_ENV === 'production' && !allowedRemotes.has(url)) {
throw new Error('远程模块地址不在白名单中');
}
return import(/* webpackIgnore: true */ url);
}
代码里通过白名单和 HTTPS 校验，避免开发环境随意使用本地地址，同时在生产环境对远程入口做强约束。webpackIgnore 注释告诉 Webpack 不要对该动态导入做额外处理，直接把加载交给浏览器。这样既能利用原生动态 import 的异步能力，又能把安全控制放在业务层。
另一个重要的安全实践是共享依赖的版本控制。在模块联邦中，多个远程应用可能依赖同一个库的不同版本。如果不加约束，运行时可能出现多个 React 实例，导致 Hook 状态混乱，也增加了补丁遗漏的风险。配置 shared 时使用 singleton: true 和 requiredVersion，可以强制所有远程模块复用同一个主版本，并让 Webpack 在版本不匹配时给出明确警告。
落地安全宇宙时最容易踩的坑
第一个坑是把远程入口地址直接写在 HTML 里，然后通过 script 标签加载。这样做不仅绕过了 Webpack 的模块解析机制，还很难做完整性校验。正确做法是让宿主应用通过 ModuleFederationPlugin 的 remotes 声明远程，由 Webpack 统一生成加载代码。如果必须单独加载远程入口，也要在 script 标签上补充 integrity 或使用非对称签名验证文件指纹。
第二个坑是忽视了 CSP 对 Trusted Types 的影响。很多团队为了安全设置了严格的 Content-Security-Policy，比如 script-src 'self'，这会导致 Webpack 生成的运行时脚本无法执行。启用 output.trustedTypes 后，需要同步调整 CSP 中与脚本相关的指令，允许 trusted-types 策略。否则会出现构建成功、页面却白屏的情况。通常可以将策略名与 Webpack 配置保持一致，并在测试环境充分验证。
第三个坑是过度信任共享依赖。singleton: true 只能保证主版本相同，不能保证补丁版本一致。如果某个远程应用锁定了旧的小版本并被强制共享，可能导致安全漏洞被放大。建议在 CI 流程中增加依赖审计，检查所有 federated 模块的 lockfile，确保共享包的小版本也处于安全范围内。
综合来看，Secure Universe 并不是一个神秘特性，而是 Webpack 5 输出安全能力与模块联邦协作模式的组合实践。获得宇宙的过程，本质上是通过配置白名单、强化输出策略、约束共享依赖和同步 CSP，让多个应用在一个可控边界内安全地运行。把这套机制落地，你的微前端架构才能既有联邦的灵活性，又有较硬的安全底线。