Web Worker线程池需解决调度、复用、错误隔离与资源退化四大问题，应基于navigator.hardwareConcurrency动态初始化（上限Math.min(..., 6)），按需启动、空闲轮询、超时控制、崩溃自愈及Transferable精准配合。
直接上结论：Web Worker 线程池不是“创建一堆 new Worker() 就完事”，而是要解决调度、复用、错误隔离和资源退化这四个实际问题。硬塞 8 个 Worker 到 2GB 内存的安卓机上，大概率卡死主线程或触发 OOM kill。
怎么初始化一个可伸缩的 Worker 池
别写死数量，先读 navigator.hardwareConcurrency，但必须 fallback；池大小上限建议取 Math.min(navigator.hardwareConcurrency || 4, 6)。重点是：池本身不预热，只预留容量，首次任务来时才按需启动 Worker 实例。
- 用
Map存活 Worker 实例（key 是 id，value 是Worker对象），避免重复创建 - 每个 Worker 加载时传入唯一
id，方便后续路由消息：new Worker(new URL('./worker.js', import.meta.url), { type: 'module' }) - Worker 脚本里用
self.name或初始化时接收的id标识自身，避免消息乱串 - 不推荐全局共享单个
Worker实例——并发请求会排队，失去并行意义
如何让任务真正“排队—分发—回收”而不是堆积
主线程不能裸调 postMessage()，得套一层 Promise 队列 + 空闲 Worker 轮询机制。否则多个任务同时进来，可能全挤到同一个 Worker 上，其他 Worker 闲着。
- 维护一个
idleWorkers: Set<Worker>，Worker 完成任务后自动回归 idle 状态 - 任务入队时，检查
idleWorkers.size > 0，有空闲就立刻分发；否则推入pendingQueue: Array<Task> - Worker 返回结果后，触发
onmessage回调，并把该 Worker 放回idleWorkers - 加超时控制：对每个任务设
setTimeout(() => reject('timeout'), 5000)，防止 Worker 卡死无响应
Worker 崩溃了怎么不拖垮整个池
一个 Worker 报错（比如 self.onerror 触发）默认不会影响其他 Worker，但若不处理，主线程收不到任何反馈，任务就永远 pending。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 主线程监听每个 Worker 的
onerror：一旦触发，立即worker.terminate()并从池中移除，再补一个新 Worker - Worker 内必须写
self.onerror = e => self.postMessage({ type: 'error', ...e })，把错误结构化透传出来 - 避免在 Worker 中用
try/catch包住全部逻辑——它捕不到异步错误（如fetch失败、setTimeout内抛错），仍需靠self.onerror - 对频繁崩溃的 Worker（比如 1 分钟内崩 3 次），直接降级为禁用该实例，改由主线程降级执行
transferable 怎么配合线程池避免内存爆炸
池里多个 Worker 共享同一类计算逻辑，但数据是隔离的；传大 buffer 不用 transfer，10MB 数据拷贝一次就卡 200ms，传三次就卡半秒。
- 只对
ArrayBuffer、TypedArray、ImageBitmap等支持 transfer 的类型启用第二个参数：worker.postMessage({ data }, [data.buffer]) - 主线程传完后，原
buffer自动变成byteLength: 0，别再读——静默失败，不报错 - Worker 收到后，直接用
new Uint8Array(e.data.data)，不用再slice或copy - 池管理器需记录哪些任务用了 transfer，避免在重试时误传已失效的 buffer
真正难的不是启动几个 Worker，而是让它们像线程池一样“活”着：能扛错、能伸缩、能回收、不抢资源。很多项目卡在“第一次能跑通”，但压测一上来就掉连接或内存飙高——问题往往出在没做 idle 状态管理，或 transfer 后忘了判空 buffer。
