并发读取多文件局部字节块本身不直接加速哈希签名，真正提速在于i/o与cpu解耦、多核并行及规避主线程阻塞，关键依赖“分片+worker+零拷贝”协同。
可以，但需注意：并发读取多文件局部字节块本身不直接“加速哈希签名”，真正提速的是把 I/O 与 CPU 计算解耦、利用多核并行处理，并规避主线程阻塞。关键不在“多文件”，而在“分片+Worker+零拷贝”三者协同。
为什么局部字节块读取更可行
大文件无法整载入内存（如 2GB 文件触发 OOM），File.slice() + FileReader.readAsArrayBuffer() 是标准解法：
- 每个 slice 返回新 Blob，只加载指定区间（如 0–1MB、1MB–2MB），内存压力可控
- 主线程可按需发起多个 slice 读取，不等待前一个完成
- 读出的 ArrayBuffer 可通过 transferable 零拷贝传给 Worker，避免内存复制开销
并发处理多文件的合理策略
同时处理多个文件时，盲目增加 Worker 数量反而降低效率。应分层控制：
- 外层按文件并发：例如最多同时处理 3 个文件（防系统 I/O 竞争）
- 内层按分片并发：每个文件再拆成若干 chunk（如每片 4MB），由单个 Worker 串行或小批量并行计算其哈希
- Worker 实例复用：不为每个 chunk 新建 Worker，而是用固定池（如 4 个 Worker）轮询接收任务
哈希合并必须匹配算法语义
局部块哈希不能简单拼接字符串再哈希——这会破坏标准哈希的抗碰撞性和一致性。正确做法分两类：
- 若目标是标准 SHA-256/SHA3：必须按原始算法规范流式追加（如 Crypto.subtle.digest() 支持 update + digest），Worker 需保持状态，逐块 feed，最后一次性出结果
- 若用于秒传/去重（不要求标准值）：可用 Merkle 式分片哈希——每块独立算 SHA-256，再将所有 32 字节结果拼成新 buffer，二次哈希得最终指纹，速度快且支持断点
主线程需主动管理资源与进度
避免内存泄漏和 UI 失控：
- FileReader 加载完成立即释放 ArrayBuffer 引用（
buffer = null），促 GC - 每个 Worker 完成后，检查是否还有待处理 chunk；无则调用
worker.terminate() - 用
postMessage({ type: 'progress', fileIndex, chunkIndex, total })向主线程同步细粒度进度
