HTML5中Web Worker预处理敏感数据的核心是剥离加密、脱敏等计算密集型操作，保障UI流畅并分担后端压力；需依托Web Crypto API安全执行标准算法，密钥通过importKey导入，IV唯一生成，数据零拷贝传输，Worker仅输出结果、不参与业务逻辑，且须用户授权、状态可见、闭环验证。
在 HTML5 中，用 Web Worker 对前端敏感数据做预处理，核心是把加密、脱敏、签名、哈希等计算密集型操作从主线程剥离，既保障 UI 流畅，又分担后端压力。关键不在“能不能做”，而在于“安全地做、高效地做、可控地做”。
选对加密能力：优先用 Web Crypto API，不手写算法
Worker 环境支持 crypto.subtle，能原生执行 AES-GCM、RSA-OAEP、SHA-256 等标准算法，性能好且安全可信。不要在 Worker 里引入第三方 JS 加密库（如 forge），既增加体积，又可能引入侧信道风险。
- 先检查环境：
if (typeof crypto !== 'undefined' && crypto.subtle)，不支持时降级提示或交由后端兜底 - 密钥必须通过
importKey()导入，不能传明文字符串；建议用 PBKDF2 衍生密钥，盐值由主线程生成并传入 - 每次 AES 加密必须用唯一 IV，用
crypto.getRandomValues(new Uint8Array(12))生成，不可复用
设计合理的预处理流程：分离输入、计算、输出三阶段
敏感数据预处理不是“一股脑塞进去”，而是分步控制：主线程负责采集和校验原始数据（如用户身份证号、银行卡号），Worker 负责执行脱敏逻辑（如掩码、哈希、国密 SM4 加密），主线程再决定是否提交、如何提交。
- 例如手机号脱敏：主线程传入
{ raw: '13812345678', rule: 'mask-last4' }，Worker 返回'1381234****'，不接触真实号码的 DOM 或变量引用 - 例如文件哈希：用户选中大文件后，主线程读取为
ArrayBuffer，用postMessage(..., [buffer])零拷贝传给 Worker；Worker 调用crypto.subtle.digest('SHA-256', buffer)，返回 base64 哈希值，后端仅需比对哈希而非传输整份文件 - 避免在 Worker 中拼接 URL 或构造请求体——这些属于业务逻辑，应由主线程完成，Worker 只输出干净结果
规避常见安全与性能陷阱
Worker 是“后台帮手”，不是“信任代理”。它运行在同源上下文，但代码一旦加载就不可信，尤其当脚本路径来自动态拼接或 CDN 时。
立即学习“前端免费学习笔记（深入）”；
- Worker 脚本必须用绝对路径或 Blob URL 加载，禁用相对路径（如
new Worker('./encrypt.js')易因页面路径变化失效，也难审计） - 敏感原始数据（如未脱敏身份证号）绝不能存入
localStorage或sessionStorage；Worker 内存中的ArrayBuffer在任务结束后会自动释放，无需手动清零（但若长期驻留，可用buffer.fill(0)主动擦除） - 单个 Worker 不宜长期存活。完成一次预处理后，调用
self.close()结束线程；高频场景可复用，但需设置超时自动终止（如 30 秒无消息则退出）
配合后端形成闭环：让预处理真正减负
前端预处理的价值，取决于后端是否信任并验证该结果。不能只“算完就发”，而要建立轻量协同机制。
- 例如上传前加签：Worker 用私钥对文件元信息（大小、类型、哈希）生成 JWT，主线程将 JWT 和文件一起提交；后端用公钥验签，确认数据未被篡改且确实经前端预处理
- 例如字段级加密：Worker 对“家庭住址”字段 AES 加密后传回，主线程将密文填入表单 hidden 字段；后端收到后直接入库，不再重复加解密
- 所有预处理操作都应在用户明确授权后触发（如勾选“我已阅读隐私协议”），并在 UI 显示“正在本地处理…”状态，不隐藏行为、不制造黑盒
