在前端构建工具 Webpack 的讨论中，偶尔会看到一种说法：Webpack 5 引入了安全多方计算（Secure Multi-Party Computation，简称 SMPC）新特性。这种说法并不准确。Webpack 5 的官方更新日志和文档中从来没有出现过安全多方计算这一项，它更多是对模块联邦（Module Federation）或持久化缓存等安全增强功能的误读。安全多方计算是密码学中一个专门研究方向，与 JavaScript 打包工具的核心职责几乎没有任何交集。本文先厘清 Webpack 5 真正的新特性，再解释安全多方计算是什么，最后分析混淆的可能来源。
Webpack 5 的真实新特性一览
Webpack 5 是构建工具 Webpack 的一次重要大版本升级，官方文档列出了多个关键变化。其中最受关注的是模块联邦（Module Federation），它允许不同构建产物在运行时动态共享模块，让微前端架构不再依赖复杂的全局变量或构建时耦合。另一个大幅提升构建效率的特性是持久化缓存，它把中间结果写入磁盘，使得二次构建可以跳过大量重复工作。除此之外，Webpack 5 还引入了资源模块（Asset Modules）来替代传统的 file-loader 和 url-loader，改进了 Tree Shaking 算法，并内置了对 Web Worker 的原生支持。
这些新特性解决的都是前端工程化中的实际问题：构建速度、代码复用、资源处理和包体积优化。从官方发布说明到社区教程，从未出现“安全多方计算”这一术语。实际上，安全多方计算要求参与方之间进行复杂的密码学交互，这与打包工具在单机或 CI 环境中处理文件转换的任务完全不同。下面这段配置展示了 Webpack 5 中模块联邦的基本用法，它体现了多方协作，但仅限于代码共享。
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
// ... 其他配置
plugins: [
new ModuleFederationPlugin({
name: 'app_host',
remotes: {
app_remote: 'app_remote@http://localhost:3001/remoteEntry.js',
},
shared: {
react: { singleton: true },
'react-dom': { singleton: true },
},
}),
],
};
可以看到，这段配置只是声明了一个远程模块地址和共享依赖策略，并没有涉及任何私有数据保护或密码学计算。如果开发者按照网上一些文章的说法，以为这里包含了安全多方计算能力，就会在技术选型和架构设计中产生根本性误判。
安全多方计算解决的是什么问题
安全多方计算是密码学中的一个研究分支，目标是让多个参与方在不泄露各自私有输入的前提下，共同计算一个约定好的函数。举个简单例子：Alice 和 Bob 都想知道谁的工资更高，但两人都不愿意透露具体数字。通过安全多方计算协议，他们可以得出比较结果，同时任何一方都无法得知对方的工资数额。这种能力在联合风控、医疗数据分析、跨机构统计等场景中非常有用。
实现安全多方计算的常见技术路线包括秘密共享、混淆电路和同态加密等。秘密共享将秘密拆分成多个碎片分发给不同参与方，只有凑齐足够数量的碎片才能恢复秘密，单独一方无法获得任何有效信息。混淆电路则把计算逻辑编译成加密的布尔电路，参与方在电路上逐门计算却看不到中间结果。这些技术在理论上已经很成熟，但在工程实现中仍有较高计算和通信开销。
# 简单的加法秘密共享示例
import random
def share(secret, num_parties=3):
shares = [random.randint(0, 1000) for _ in range(num_parties - 1)]
last_share = secret - sum(shares)
shares.append(last_share)
return shares
def reconstruct(shares):
return sum(shares)
# Alice 的秘密值为 42
shares = share(42)
print(reconstruct(shares)) # 输出 42
上面的 Python 代码演示了一种朴素的加法秘密共享：把秘密拆成三个随机部分，只有把三个部分加在一起才能还原原始秘密，单独看任何一个碎片都无法推断出 42 这个值。真实的安全多方计算协议远比这个复杂，需要处理恶意参与方、网络同步和结果验证等问题。因此，它通常由专门的密码学库实现，不可能作为 Webpack 配置中的一个开关出现。
为什么会产生这种混淆
混淆来源主要有几个方面。第一是 Module Federation 的名称中带有 Federation，且它允许两个甚至多个独立部署的应用在运行时互相加载模块，表面上看确实涉及多个参与方。一些写作者没有深入理解这个特性的本质，就把“多应用共享模块”错误地等同于“多方安全计算”。第二是 Webpack 5 在安全性方面确实做了一些增强，例如更严格的模块解析规则、持久化缓存的文件指纹校验，以及更谨慎的全局变量处理。但这些安全增强只是构建工具内部的可靠性措施，远不是密码学意义上的安全多方计算。
下面这段配置展示了 Module Federation 中远程应用暴露模块和宿主应用消费模块的典型写法。两个应用分别由不同团队维护，但它们之间的协作是完全公开的代码共享，不存在任何需要隐私保护的输入。
// remote 应用 webpack.config.js
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'remote_app',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button',
},
}),
],
};
// host 应用 webpack.config.js
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'host_app',
remotes: {
remote_app: 'remote_app@http://localhost:3002/remoteEntry.js',
},
}),
],
};
如果两个团队之间还需要保护某些敏感商业逻辑，安全多方计算或许能提供帮助，但这与 Webpack 5 的模块联邦没有直接关系。把两者混为一谈，不仅会误导初学者，还可能让团队对微前端方案产生不切实际的安全预期。
如何准确获取 Webpack 5 的技术信息
面对这类看似新奇的说法，最有效的办法是回到权威信息源。Webpack 官方文档和 GitHub 仓库的 release notes 是了解新特性的第一手资料。在官方渠道中搜索安全多方计算或 Secure Multi Party Computation，不会得到任何相关条目。相反，搜索 Module Federation、Persistent Caching、Asset Modules 等关键词，可以找到详细的说明和示例。养成查阅原始文档的习惯，可以避免被二手文章中的术语错误带偏。
此外，也可以借助 npm 命令快速确认 Webpack 5 的版本和包信息，判断自己安装的版本是否包含某些特性。下面的命令可以查看当前 Webpack 的最新版本和发布包地址，有助于确认文档与所使用版本之间的对应关系。
npm view webpack version npm view webpack dist.tarball
理解一个技术术语的准确含义，是工程师专业素养的一部分。安全多方计算在隐私计算领域有着重要价值，但它和前端构建工具分属不同技术层次。正确区分二者，不仅能提升个人技术判断力，也能在团队讨论和方案评审中避免犯下概念性错误。Webpack 5 真正的亮点在于模块联邦和构建效率提升，而不是一个并不存在的密码学新特性。