必须用 Worker 是因为大文件哈希会阻塞主线程导致页面假死，而 Worker 在独立线程运行，配合 ArrayBuffer 传递和 Web Crypto API 可实现非阻塞、可中断、带进度的分片哈希计算。
用 Worker 线程做前端大文件分片 Hash 计算，核心是把耗时的哈希运算从主线程剥离，避免页面卡顿，同时利用分片 + Web Crypto API（如 SubtleCrypto.digest()）实现高效、可中断、可进度反馈的计算流程。
为什么必须用 Worker？
大文件（比如几百 MB 的视频或镜像）在主线程中逐块读取并计算 SHA-256，会阻塞渲染和交互，导致页面“假死”。而 Worker 运行在独立线程，配合 ArrayBuffer 传递二进制数据，能真正实现并发计算。注意：不能直接传 File 对象给 Worker，需传 ArrayBuffer 或使用 structuredClone（需开启 transferable 支持）。
分片策略与 Hash 拼接逻辑
常见做法不是对整个文件哈希，而是先分片计算每片哈希，再对所有片哈希值拼接后二次哈希（类似 Merkle 树根哈希），兼顾性能与唯一性：
- 按固定大小切片（如 1MB/片），最后一片不足也单独处理
- 每片用
crypto.subtle.digest('SHA-256', sliceArrayBuffer)计算哈希 - 收集所有片哈希的
Uint8Array，合并成一个长 buffer，再整体哈希一次 → 得到最终文件指纹 - 也可选择“片哈希拼接为字符串后 UTF-8 编码再哈希”，但推荐二进制拼接更严谨
Worker 内部实现要点
Worker 脚本需主动管理内存和流程，避免堆积 ArrayBuffer：
立即学习“前端免费学习笔记（深入）”；
- 接收主线程传来的
fileData: ArrayBuffer和chunkSize: number - 用
for (let i = 0; i 切片，用 <code>fileData.slice(i, i + chunkSize)获取子 buffer - 每次调用
crypto.subtle.digest()返回 Promise，用await串行或Promise.all()并行（注意浏览器并发限制，通常 4–8 片并发较稳） - 计算中通过
postMessage({ type: 'progress', loaded: i, total: fileData.byteLength })向主线程同步进度 - 最终将所有片哈希合并、二次哈希，返回十六进制字符串结果
主线程调用与资源清理
主线程负责读取文件、启动 Worker、监听消息并释放资源：
- 用
file.arrayBuffer()读取全文件（注意内存占用，超大文件建议用Stream+ReadableStreamBYOBReader分批读，但 Worker 不支持流，需折中） - 创建 Worker：
const worker = new Worker('/hash-worker.js')，传入{ fileData, chunkSize }，并设置worker.postMessage(... , [fileData])实现零拷贝传输 - 监听
message处理进度和结果，收到完成消息后立即调用worker.terminate()避免内存泄漏 - 若用户取消，主线程发
worker.postMessage({ type: 'cancel' })，Worker 内部需监听并return退出循环
不复杂但容易忽略：分片大小需权衡——太小（如 64KB）导致 Promise 过多、调度开销大；太大（如 10MB）单次哈希耗时长、进度粒度粗。实测 512KB–2MB 是多数场景较优区间。另外，Safari 对 SubtleCrypto.digest 在 Worker 中的支持较晚（iOS 16.4+），上线前务必兼容性检测。
