Generator本身不能防止主线程卡顿，它仅提供可中断的执行机制；真正起效的是配合事件循环做时间分片，将CPU密集任务切块并让出控制权，但大文件哈希仍应交由Web Worker处理。
Generator 本身不能直接防止主线程卡顿，它只是提供一种可中断、可恢复的函数执行机制；真正起作用的是配合事件循环调度（如 setTimeout 或 requestIdleCallback）做时间分片，把大文件哈希这类 CPU 密集型任务“切成小块”，让出主线程控制权给渲染和用户交互。
Generator 是分片执行的“脚手架”，不是性能解药
Generator 函数（带 * 的函数）返回一个迭代器，每次调用 .next() 只执行到下一个 yield，暂停并交出控制权。这为手动拆分长任务提供了天然结构，但它不自动异步——若在主线程里连续调用 .next() 不加等待，依然会阻塞页面。
- 它适合封装“每处理一片就 yield 一次”的逻辑，比如逐片读取 ArrayBuffer、调用
crypto.subtle.digest - 但它必须搭配宏任务（如
setTimeout）或空闲调度（requestIdleCallback）才能真正释放主线程 - 对大文件哈希这种纯计算任务，Generator + 主线程调度的效率远不如 Web Worker——因为主线程仍要承担 digest 调用、buffer 拼接等开销
为什么大文件哈希不该放主线程做（哪怕用了 Generator）
哪怕你用 Generator 把 1GB 文件切成 1000 片，每片调用一次 crypto.subtle.digest('SHA-256', chunk)，这些 Promise 在主线程并发执行时，仍会触发浏览器对 SubtleCrypto.digest 的内部限流（通常 ≤4 并发），其余请求排队；同时频繁创建 Uint8Array、拼接 buffer、GC 回收，都会加剧主线程压力，导致动画掉帧、输入延迟。
-
File对象不能传入 Worker，但ArrayBuffer可以零拷贝传递——这是必须走 Worker 的关键前提 - 主线程只负责：读取文件 →
file.arrayBuffer()（注意内存风险）→ 分片 → 传给 Worker - Worker 内用 Generator 或普通循环做分片 digest，完全不干扰 UI
Generator 在这个流程里真正该用在哪
它更适合用在主线程侧的协调与状态管理，而非核心计算：
立即学习“Java免费学习笔记（深入）”；
- 封装上传进度控制器：每完成一片上传（非计算），
yield { progress: x%, chunkId: n }，供 UI 更新 - 实现断点续传的状态机：用
yield* uploadStep1(); yield* uploadStep2();清晰表达流程依赖 - 配合
requestIdleCallback做低优先级预处理，比如提前解析文件元数据、生成上传签名等轻量任务
正确姿势：Generator + Worker 各司其职
主线程用 Generator 管理流程节奏，Worker 专注哈希计算：
- 主线程：
async function* hashWorkflow(file) { const buf = await file.arrayBuffer(); const worker = new Worker('hasher.js'); worker.postMessage({ buffer: buf, chunkSize: 3 * 1024 * 1024 }, [buf]); for await (const msg of eventChannel(worker)) yield msg; } - Worker：
onmessage = async ({ data }) => { const { buffer, chunkSize } = data; const hashes = []; // 用普通 for 循环分片，Promise.all 控制并发 ≤4 … postMessage({ type: 'chunkDone', hash }); }; - 这样既避免主线程卡死，又保证哈希结果可复现（二进制拼接、统一 digest 流程）
