直接把加密任务扔进 Web Worker 能显著缓解主线程压力、避免卡顿，本质是将计算密集型任务移至后台线程以保障 UI 响应；适用场景包括 AES-256/ChaCha20 大文件加解密、RSA/ECDSA 密钥生成、大文件哈希校验等纯计算且单次≥50ms的任务，需配合分块处理、transferable objects 传输、动态 Worker 数量控制及主线程轻量更新等策略才能真正提升体验。
直接把加密任务扔进 Web Worker，能显著缓解主线程压力，让页面不卡顿——这不是降低总 CPU 消耗，而是把重活挪到后台线程，把 UI 响应权还给用户。
哪些加密场景适合用 Worker
不是所有加密都值得上 Worker。真正受益的是那些计算量大、耗时明显、且不依赖 DOM 的任务：
- AES-256 或 ChaCha20 对 MB 级数据的加解密
- RSA 或 ECDSA 密钥生成（尤其是 4096 位 RSA）
- 大文件的 SHA-256/SHA-3 校验（如上传前哈希）
- JWT 签名验证或批量 token 解析
- 零知识证明中的多项式承诺运算等密码学原语
关键优化点：别只建个 Worker 就完事
Worker 本身不自动变快，得配合具体策略才能发挥并行优势：
- 对超大文件分块处理，比如每 64KB 调一次
crypto.subtle.encrypt，中间用setTimeout(() => {}, 0)让出控制权，避免单个 Worker 长时间霸占一个核 - 传递加密数据时，用
ArrayBuffer+ transferable objects（第二参数传[buffer]），实现零拷贝，避免结构化克隆带来的延迟 - 根据设备核心数动态启 Worker：读取
navigator.hardwareConcurrency，4 核设备通常配 2 个加密 Worker 更稳，8 核可上 3–4 个 - 小数据（如几十字节的短文本 AES 加密）反而不适合 Worker——创建和通信开销可能超过计算本身
Worker 内必须绕开的坑
加密逻辑搬进去后，有些事它做不了，硬来会报错或降级：
- 不能访问
document、window、localStorage，密钥若存在 localStorage，得主线程读出后通过postMessage传入 -
WebCrypto API在 Worker 中基本可用，但部分非标准算法（如某些国密 SM2 变种或自定义曲线）需提前用self.crypto.subtle?.digest或encrypt检测支持性 - 无法直接操作 DOM 更新进度条——进度得由 Worker 定期发消息（如
{ type: 'progress', percent: 37 }），主线程再渲染 - 多个 Worker 同时调用
crypto.subtle不会冲突，但若共用同一密钥对象（如importKey返回的CryptoKey），需确保主线程导入后正确 transfer 过去
实测效果看什么指标
别光看“算得快”，重点验证用户体验是否真实提升：
- 用 Chrome DevTools Performance 面板观察主线程：加密期间应无长任务（
Evaluate Script块消失，CPU 曲线平缓） - 滚动页面或拖拽元素时帧率保持在 55–60 FPS（同步加密下常掉到 10 FPS 以下）
- 首屏交互延迟下降 40%~70%（例如点击“加密”按钮到显示“完成”提示的时间）
- Task Manager 中查看：主线程 CPU 占比明显回落，Worker 进程独立占用对应核心
