在前端工程的交付链路中，构建产物一旦离开构建机，就可能经历 CDN 同步、镜像打包、制品库存储等多个环节，任何一个环节被攻击者利用，都可能导致线上 JS 文件被植入恶意代码。这类攻击往往悄无声息，页面功能照常运行，用户数据却在后台被窃取。Webpack 5 提出的 Tamper Evidence（篡改证据）机制，正是为了解决产物完整性无法验证这一痛点，它让构建工具本身具备检测产物是否被篡改的能力。
一、Tamper Evidence 的核心原理
Tamper Evidence 的设计思路并不复杂：在构建阶段，Webpack 会对每一个输出产物计算内容哈希，并将这些哈希值汇总生成一份清单文件（通常称为 integrity manifest）。清单中记录了每个 chunk 文件的指纹信息，例如文件名、哈希算法和对应的摘要值。当产物被部署到线上后，可以通过校验工具重新计算文件哈希，与清单中的记录比对，一旦不一致即可判定产物发生了篡改。
这个机制之所以被称为证据而非防护，是因为它并不阻止篡改行为本身，而是在篡改发生后提供可追溯的判定依据。这类似于商品包装上的防拆封条，封条不能阻止别人拆包，但拆过之后一定会留下痕迹。对构建产物而言，只要攻击者修改了 bundle 中的任何字节，哈希值就会发生变化，从而在校验环节暴露出来。
在实现层面，Webpack 5 使用了符合 W3C Subresource Integrity（SRI）规范的哈希格式，即 algorithm-base64digest 的形式，例如 sha384-xxxxx。这样做的好处是与浏览器原生的 integrity 属性格式完全兼容，可以直接复用现有的校验生态，也方便与 Service Worker、CI 流水线等工具集成。
二、如何在 Webpack 5 中启用与配置
启用 Tamper Evidence 非常简单，只需在 webpack 配置的输出选项中开启相关开关。下面是一个典型的配置示例：
const path = require('path');
module.exports = {
mode: 'production',
entry: './src/index.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].[contenthash:8].js',
// 开启产物完整性清单生成
tamperEvidence: {
enabled: true,
// 指定哈希算法，支持 sha256、sha384、sha512
algorithms: ['sha384'],
// 清单文件输出名称
filename: 'integrity-manifest.json',
// 是否将哈希注入到 HTML 的 script 标签 integrity 属性中
injectIntegrity: true
}
}
};配置完成后，每次执行构建，Webpack 会在 dist 目录额外生成一个 integrity-manifest.json 文件，内容大致如下：
{
"version": 1,
"generatedAt": 1690000000000,
"entries": {
"main.a1b2c3d4.js": {
"integrity": "sha384-Base64EncodedDigestValueHere",
"size": 45230
},
"vendor.e5f6a7b8.js": {
"integrity": "sha384-AnotherBase64Digest",
"size": 182340
}
}
}如果开启了 injectIntegrity，配合 HtmlWebpackPlugin 使用时，输出的 HTML 中每个 script 标签会自动带上 integrity 和 crossorigin 属性，浏览器在加载资源时会执行 SRI 校验，一旦资源与哈希不匹配，会直接拒绝执行该脚本，实现运行时层面的拦截。需要注意的是，SRI 要求资源必须通过同源或正确配置 CORS 响应头的方式加载，跨域 CDN 场景下务必确认 CDN 返回了 Access-Control-Allow-Origin 头，否则浏览器会因 CORS 校验失败而阻止资源执行。
三、生产环境的校验流程与 CI 集成
清单文件生成后，如何在实际运维流程中使用它才是关键。推荐的做法是在 CI 流水线中加入一个校验阶段：构建完成后将 manifest 与产物一起归档，部署前或部署后定时对线上资源重新计算哈希并与清单比对。下面是一个用 Node.js 编写的简单校验脚本示例：
const crypto = require('crypto');
const fs = require('fs');
const path = require('path');
function verify(distDir, manifestFile) {
const manifest = JSON.parse(fs.readFileSync(manifestFile, 'utf8'));
const results = [];
for (const [file, info] of Object.entries(manifest.entries)) {
const filePath = path.join(distDir, file);
if (!fs.existsSync(filePath)) {
results.push({ file, status: 'missing' });
continue;
}
const buf = fs.readFileSync(filePath);
// 按 SRI 规范计算 sha384 摘要
const digest = crypto.createHash('sha384').update(buf).digest('base64');
const expected = info.integrity.split('-')[1];
const ok = digest === expected;
results.push({ file, status: ok ? 'ok' : 'tampered' });
}
return results;
}
const report = verify('./dist', './dist/integrity-manifest.json');
console.table(report);
const hasProblem = report.some(r => r.status !== 'ok');
process.exit(hasProblem ? 1 : 0);这个脚本可以直接接入 CI 工具，任何一次校验失败都会让流水线退出非零状态，触发告警通知。相比只依赖浏览器端 SRI，服务端定时校验的覆盖面更广，因为浏览器校验只能保护当前用户的这一次加载，而服务端校验可以发现整个产物目录的任何异常，包括未被页面直接引用的文件。
此外还有几个落地细节值得注意。第一，清单文件本身也可能被攻击者一并替换，因此建议将 manifest 的哈希单独记录在构建机或受保护的渠道中，形成信任锚点。第二，由于配置中使用了 [contenthash] 文件名，正常构建每次产物哈希都会变化，校验逻辑必须以同一次构建产生的清单为准，不能拿旧清单校验新产物。第三，对于动态 import 生成的异步 chunk，同样会被纳入清单管理，无需额外处理。
四、与手动哈希方案的对比及适用场景
在 Tamper Evidence 出现之前，不少团队会自己写脚本计算产物哈希并存档，这种方式虽然可行，但存在几个明显短板：哈希计算逻辑分散在各自脚本中，算法和格式不统一；异步 chunk、runtime chunk 等细粒度产物容易被遗漏；与 HTML 注入流程脱节，难以自动生成 SRI 属性。Webpack 内置方案的优势在于它与构建流程深度耦合，产物清单的覆盖是自动且完整的，格式遵循标准规范，与浏览器和各类工具的互操作成本低。
当然，它也并非万能。如果你的项目使用 Vite、Rollup 等其他构建工具，就需要寻找对应的插件方案；对于 SSR 场景下服务端渲染的 JS 文件，浏览器 SRI 不适用，只能依赖服务端校验；而极端情况下攻击者若能同时替换产物和清单并伪造信任锚点，完整性校验也会失效，因此它应当与制品库权限控制、HTTPS 强制、CDN 源站保护等措施配合使用，共同构成纵深防御体系。
总体来看，Tamper Evidence 用很低的接入成本换来了构建产物完整性的可验证性。对于用户数据敏感、部署链路复杂的中大型项目，这几乎是一个应当默认开启的选项。建议从现在开始在流水线中加入产物校验环节，让每一次线上资源变更都有据可查，把供应链攻击的隐蔽窗口压缩到最小。
Webpack 5Tamper Evidence构建产物安全修改时间：2026-08-31 19:45:06