worker_threads 仅能缓解 cpu 密集型阻塞，对同步 i/o（如 fs.readfilesync）、同步解析或忙等待等阻塞事件循环的操作无效，主线程仍会卡死。
为什么主线程卡死时，worker_threads 不一定救得了你
因为 worker_threads 只解决 CPU 密集型阻塞，不解决 I/O 阻塞或事件循环被大量微任务拖垮的问题。如果你的“计算密集型”其实是同步读文件、递归 JSON 解析、或者 while (Date.now() 这类伪计算，开线程也白搭——主线程照样卡。
实操建议：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 先用
process.cpuUsage()和performance.now()确认耗时真在 CPU 上，而不是等磁盘或陷入无限循环 - 避免在线程里调用
console.log、require或访问process.env（除非显式传入），这些会触发 IPC 序列化开销甚至隐式同步 - 别在线程里
throw错误后指望主线程自动捕获——必须监听worker.on('error')或用worker.postMessage({ type: 'error', msg })主动上报
Worker 实例传参要注意什么
主线程和工作线程内存不共享，所有数据靠 postMessage 复制传递。传大对象（比如 10MB 的 ArrayBuffer）默认会深拷贝，慢且吃内存。
实操建议：
- 传原始类型（
number、string、boolean）或小结构体没问题；传大数组优先用SharedArrayBuffer+TypedArray零拷贝（但需手动同步） - 避免传函数、
Date、RegExp、undefined——它们会被序列化成null或抛错 - 如果要传配置对象，先
JSON.stringify再postMessage，线程里JSON.parse，比直接传对象更可控
怎么避免 Worker 创建/销毁开销反超收益
每次 new Worker('./task.js') 都要初始化 V8 实例、加载模块、启动事件循环——对短任务（
实操建议：
- 对高频小任务，用
Worker池（比如tiny-worker-pool或手写复用逻辑），让 Worker 持续监听message事件，处理完不退出 - Worker 文件尽量精简：不要
require('lodash')，别 import 整个moment，用啥写啥 - 用
worker.unref()防止 Worker 阻止进程退出（尤其 CLI 工具中）
常见报错：ERR_WORKER_PATH_NOT_FOUND 和 ERR_WORKER_UNSUPPORTED_EXTENSION
这两个错基本都指向路径或模块格式问题。Node.js 的 worker_threads 默认只认 .js 和 .mjs，不支持 .ts、.cjs 或相对路径解析错误。
实操建议：
- Worker 脚本路径必须是绝对路径，用
path.resolve(__dirname, './worker.js')，别用./worker.js - TS 项目必须先编译成 JS，或用
ts-node启动主进程（但 worker 仍需 JS） - ESM 项目中，若主进程是
type: "module"，Worker 脚本也得是.mjs或带"type": "module"的package.json
最常被忽略的是：线程间通信不是免费的。一次 postMessage 可能触发多次 V8 堆复制，尤其传嵌套对象时。宁可多传几次小数据，也别攒一大块再发。
