必须用web worker分片计算大文件hash以避免页面卡死；需将file转arraybuffer零拷贝传递，按2–5mb分片并控制并发≤4，uint8array二进制拼接后二次哈希，双向清理取消状态。
直接用主线程算大文件 Hash 会卡死页面，必须用 Web Worker 拆分计算任务；但光扔进 Worker 不行，传参方式、分片策略、哈希拼接逻辑稍有偏差，结果就不可复现，秒传就失效。
Web Worker 传 ArrayBuffer 而不是 File 对象
File 对象不能直接传给 Worker —— 它不是可结构化克隆的类型，强行传会导致 DATA_CLONE_ERR 或静默失败。必须先转成 ArrayBuffer，再用 transferable 方式零拷贝传递：
- 主线程调用
file.arrayBuffer()获取完整 buffer（注意：超大文件慎用，内存可能爆） - 创建 Worker 后，用
worker.postMessage({ fileData, chunkSize }, [fileData])，把fileData加入 transfer list - Worker 内收到的是可直接操作的
ArrayBuffer，无需再slice().arrayBuffer()多次转换 - 若用
File.slice()+blob.arrayBuffer()分片读取，每次都要 await，性能差且易中断；不如主线程一次读完，Worker 内纯 CPU 计算
分片大小与并发控制要匹配浏览器实际能力
5MB/片是常见折中值，但不是硬规则；关键看 crypto.subtle.digest() 并发上限和内存占用：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- Chrome/Firefox 对
SubtleCrypto.digest()的并发 Promise 数有限制（通常 4–6 个），超出会排队，反而拖慢整体耗时 - 单片太大（如 50MB）→ 单次 digest 耗时长、无法进度反馈、Worker 响应延迟高
- 单片太小（如 64KB）→ 创建太多 Promise、buffer 拼接开销上升、GC 压力大
- 实测推荐：2–5MB/片，Worker 内用
Promise.all(chunks.map(...))控制并发数 ≤ 4，比串行快 3 倍以上，又不触发限流
Hash 拼接必须二进制对齐，不能字符串拼接
很多实现把每片 SHA-256 结果转成 hex 字符串再拼接，最后再哈希——这会导致不同平台/编码下结果不一致（比如换行、大小写、空格）：
- 正确做法：每片 digest 返回
Uint8Array，用new Uint8Array(totalLength)预分配空间，按顺序.set(sliceHash, offset)写入 - 最终对这个完整 buffer 再调一次
crypto.subtle.digest('SHA-256', fullBuffer) - 如果服务端也用同样逻辑（比如 Go 的
sha256.Sum256或 Python 的hashlib.sha256().update()分段 update），才能保证秒传命中 - 别用 SparkMD5 做最终文件指纹——它不是标准 SHA-256，和服务端校验不兼容，仅适合 Worker 内部快速预估
取消与异常必须双向清理
用户点取消或网络中断时，只停主线程没用，Worker 还在跑，内存不释放，下次上传可能复用旧状态：
- 主线程发
worker.postMessage({ type: 'cancel' })，不要只靠worker.terminate() - Worker 内需监听
self.onmessage，遇到 cancel 立即return当前循环，不发后续postMessage - 主线程收到完成消息后，必须立刻调用
worker.terminate()；否则 Worker 实例常驻，ArrayBuffer 不会被 GC - 尤其注意：transfer 后的
ArrayBuffer在主线程已不可访问，别试图在 cancel 后再读它
真正难的不是“怎么起 Worker”，而是让每一片的 buffer 切得准、传得稳、哈希拼得严、取消收得净——少一个环节，秒传就变成“秒错”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
