Web Workers 排序时主线程卡顿主因是 postMessage 传递大对象触发结构化克隆阻塞；应改用 Transferable（如 ArrayBuffer）、扁平数据、避免嵌套；大数据量需自实现稳定 O(n log n) 排序；须正确绑定每个 Worker 的 onmessage 并确保 postMessage 发送；UI 更新需批量操作或虚拟滚动。
Web Workers 排序时主线程仍卡顿？检查是否在 postMessage 里传了大对象
主线程卡住，往往不是 Worker 没起作用，而是你把几 MB 的 Array 直接塞进 postMessage——这会触发结构化克隆，主线程同步阻塞，UI 照样冻结。
- 用
Transferable对象（如ArrayBuffer）代替普通数组：先用TypedArray构建数据，再调用postMessage(data, [data.buffer]) - 避免传递嵌套对象或含函数的结构；只传纯数字/字符串/扁平数组
- 如果原始数据是 JSON，先
JSON.stringify再用TextEncoder.encode()转成Uint8Array，Worker 侧用TextDecoder.decode()还原
Worker 里用 sort() 还是自己写快排？看数据规模和稳定性要求
Array.prototype.sort() 在 Worker 中可用，但 V8 和 Firefox 对超长数组（>10⁵ 元素）可能退化为 O(n²)，且默认不稳定（相同值相对顺序不保证），对分页排序或带索引的数据很危险。
- 10⁴ 以下：直接用
arr.sort((a, b) => a - b)，简单可靠 - 10⁵ 以上：改用
mergeSort或introsort实现，确保 O(n log n) 和稳定性 - 若需保留原始索引（如“排序后返回原位置”），别依赖
sort()的回调参数，改用map((v, i) => ({ v, i })).sort(...).map(x => x.i)，但注意内存开销
Chrome DevTools 显示 Worker CPU 占用 100%，但排序结果迟迟不回传？检查 onmessage 是否被覆盖
常见错误是多次 new Worker() 后，只给最后一个实例绑 onmessage，前面的 Worker 发送结果时没人接收，消息堆积在队列里，看起来像“卡住”。
- 每个 Worker 实例必须独立绑定
worker.onmessage = handler，不能复用同一个函数变量而不清理旧监听 - 用
addEventListener('message', ...)更安全，但记得removeEventListener配对（尤其 Worker 复用场景） - 在 Worker 内部，确认排序完成后调用了
postMessage(result)，且result是可转移或可克隆的——console.log不报错不代表能发出去
排序后 UI 更新慢一拍？别在主线程里循环渲染每条数据
即使排序完成，如果用 for 循环逐个 appendChild 或更新 innerHTML，重排重绘会拖垮帧率。这不是 Worker 的问题，是 DOM 操作方式错了。
- 把排序结果一次性生成
DocumentFragment或用innerHTML拼整段 HTML 字符串，再单次插入 - 列表很长时，启用虚拟滚动（virtualized list），只渲染可视区域 + 缓冲区，Worker 只负责提供有序索引映射，不参与 DOM
- 避免在
onmessage回调里做复杂计算或请求——它本该只做“接收 → 更新视图”这一件事
真正难的不是让 Worker 跑起来，而是数据怎么切、怎么传、怎么接、怎么刷——四步里任何一步没对齐 Transferable / 生命周期 / DOM 批量更新的边界，UI 就会悄悄卡住，还查不出错在哪里。
