浏览器 WebAssembly 模型资产治理：摘要校验、缓存 ABI 与安全回滚

浏览器端模型由 .wasm、JS glue、权重分片、tokenizer 和配置组成。CDN 上任一对象更新较慢，都可能让页面用错词表或算子实现。WebAssembly 基础 解释 JS 与 Wasm 协作，本篇关注下载、缓存和回滚的完整性边界。

一份清单绑定全部产物

构建流水线为每次发布生成不可变 manifest，至少记录发布 ID、每个文件的字节数与 SHA-384、runtimeAbi、模型格式、tokenizer 摘要、JS glue 版本、所需 Wasm feature 和构建工具链。URL 使用内容摘要或发布 ID，禁止让 /model/latest.bin 指向可变内容。

{
  "release": "browser-ai-2026.07.18.3",
  "runtimeAbi": "ort-web-v4",
  "features": ["simd"],
  "assets": [
    {"url": "/ai/4f2a/runtime.wasm", "bytes": 918244,
     "integrity": "sha384-BASE64_DIGEST"},
    {"url": "/ai/4f2a/model-01.bin", "bytes": 67108864,
     "integrity": "sha384-BASE64_DIGEST"}
  ]
}

摘要只证明字节与清单一致，不证明发布者可信。manifest 必须随受信 bundle 发布或由受信密钥签名；攻击者若能同时替换文件和清单，hash 就没有意义。这与 AI 供应链安全 的证据链原则一致。

加载器使用 fetch(url, { integrity })，并核对最终 URL、实际读取字节数和响应类型。Fetch 在 integrity 非空时会先完整读取并校验 body，之后才把 Response 交给调用方；因此这种 SRI 路径不能让 Wasm 编译与网络下载并行。.wasm 仍必须返回 Content-Type: application/wasm，WebAssembly.instantiateStreaming 可以避免应用层先构造 arrayBuffer()，但不能恢复已经失去的网络重叠。冷启动预算和峰值内存必须按完整资产校验计量，错误 MIME 在预发布直接失败。权重分片同样在验证完成前不能交给推理器，浏览器矩阵还要验证 SRI、重定向和跨源响应行为。

缓存命名空间必须包含 ABI

Cache Storage 按发布隔离，例如 ai-assets:browser-ai-2026.07.18.3。安装新版本时先写 staging namespace，逐项验证摘要和大小，全部通过后才把该 release 标为 ready；半套资源永远不能成为活动版本。Web 缓存策略 可以决定新鲜度，但模型资产的正确性不能依赖 TTL 或文件名猜测。

缓存命中后仍按受信 manifest 复核字节数和摘要，不能只信一条 ready 元数据。verify/use 必须绑定同一个 Response snapshot：全量方案只读取一次到受控 bytes，校验后直接消费这些 bytes；不能校验完再调用第二次 cache.match()，否则并发替换会形成 TOCTOU。Response.clone() 的 tee 也可能为慢分支缓存整份 body，不能当作零成本方案。大分片若采用内容寻址的分块摘要，分块大小、顺序和最终根摘要都进入清单，每个已验证块写入 staging 后再消费；失败就隔离整个 namespace。

加载前比较 manifest 的 runtimeAbi、JS glue 声明和模型格式。导出名称相同也可能因内存布局、dtype、operator set 或 tokenizer 变化而串版。加载器应返回 ASSET_DIGEST_MISMATCH、ABI_UNSUPPORTED、WASM_MIME_INVALID 等稳定错误，不能捕获后继续使用任意旧缓存。

旧 namespace 至少保留一个观察窗口，并受总字节预算控制。清理只删除“不活动且不在回滚集合”的完整 release；不能逐文件 LRU，因为它会制造无法复原的混合版本。离线启动只允许选择已经 ready 且与当前 loader 兼容的清单，否则展示明确的离线不可用状态。

线程能力与 cross-origin isolation 分开决策

单线程 Wasm、SIMD 和普通 Worker 不因为“用了 AI”就需要 cross-origin isolation。只有运行时确实依赖 SharedArrayBuffer 或 Wasm threads 时，才配置 Cross-Origin-Opener-Policy: same-origin 与 Cross-Origin-Embedder-Policy: require-corp（或经过验证的 credentialless），并在启动时检查 crossOriginIsolated。

这些响应头会改变 opener、iframe 和跨源资源加载，不能当作性能开关。模型、Worker、字体和遥测端点必须满足 CORS 或 CORP；可结合 CORS 与 CSP 审计。矩阵分别测试隔离与非隔离模式：缺头时选择已发布的单线程资产，没有降级包就拒绝启动。

线程版与单线程版各有独立 manifest、摘要和基准结果。清单记录目标浏览器完整版本、CPU 架构、线程数、SIMD/threads 探测结果及峰值内存。并发计算仍应放在受控 Worker 协议中，避免 UI 取消后遗留运行时；任务隔离可参考 Web Workers 并发。

用损坏与串版测试验收回滚

发布门主动注入：翻转 Wasm 一个字节、截断权重、返回 HTML 错误页、伪造 application/wasm、让 CDN 返回旧 glue、新模型混入旧 tokenizer、缓存写到一半断网、在摘要校验后并发替换缓存、配错 COEP，以及浏览器不支持 threads。网络瀑布还要证明启用 integrity 时 Response 在完整校验后才交付，并记录冷启动与峰值内存。每个用例都应在首次推理前得到预期错误码，且 staging 不得被标为 ready。

回滚不是清缓存重试。控制面把活动 release 指回上一份已验证 manifest，同时恢复匹配的 loader bundle 和线程策略；客户端停止新版本入队，等待在途任务结束或按协议终止，再从保留 namespace 重建运行时。已经落地的新资产继续隔离保存以供取证，不能让旧 loader 猜测新 ABI。若必须恢复响应头，还要单独验证窗口通信和嵌入关系。

监控按 release 汇总摘要失败、MIME 错误、ABI 拒绝、缓存命中、初始化耗时和推理校验样本，不记录用户输入。只有新版本在批准浏览器中完成冷启动、离线启动、损坏恢复和真实回滚演练，才扩大流量。可靠的端侧推理不是“Wasm 能实例化”，而是每个字节可验证、每套 ABI 可匹配、每个能力假设可检测、上一版始终可恢复。

延伸阅读

• WebAssembly 基础
• AI 供应链安全
• Web 缓存策略
• CORS 与 CSP