Worker线程池调试必须启用autoAttachChildProcesses:true且配对--inspect-brk，否则断点不生效；需在launch.json中同级配置type:"node"、显式指定port、正确设置Worker路径和sourceMaps，并手动切换线程上下文。
Worker线程池调试必须启用 autoAttachChildProcesses: true，否则断点永远不生效——这不是配置遗漏，而是调试器根本看不到 Worker 进程。
launch.json 必须加 autoAttachChildProcesses 且配对 --inspect-brk
VS Code 默认只调试主线程，autoAttachChildProcesses 是唯一能让调试器“看见” Worker 的开关。它不是可选项，不设就等于没开调试。
-
"autoAttachChildProcesses": true必须写在 launch 配置里，和"type": "node"同级 -
"runtimeArgs": ["--inspect-brk"]不能省——Worker 默认不暴露调试端口，--inspect-brk让它一启动就暂停并等待连接 -
"port"建议显式指定（如9229），避免多个 Worker 竞争同一端口导致只连上第一个 - 如果用
ts-node或esbuild-node启动，autoAttachChildProcesses会失效；改用标准node启动或换用tsx（支持该配置）
Worker 构造路径和 source map 必须能被 VS Code 定位
断点显示空心圆、悬停提示 “Breakpoint ignored because generated code not found”，基本是路径或 source map 没对上。
- Worker 文件路径必须是相对于
__dirname或绝对路径，别用./worker.js——process.cwd()可能变，VS Code 解析失败 -
new Worker('./worker.js')❌；应写成new Worker(path.resolve(__dirname, 'worker.js'))✅ - 如果用了打包（如 esbuild 输出到
dist/），launch.json 中要加"sourceMaps": true和"outFiles": ["./dist/**/*.js"] - 确认
worker.js没被files.exclude或.gitignore隐藏，否则 VS Code 不加载其源码
断点命中后必须手动切换线程上下文
VS Code 不自动跳转到 Worker 线程，即使断点触发了，变量面板和调用栈仍显示主线程内容。
- 断点暂停后，看右上角调试工具栏的线程下拉框——里面应有
Main Thread和类似Worker Thread #1的条目 - 不要靠鼠标点下拉菜单选，容易误操作；推荐快捷键
Ctrl+Shift+P→ 输入Debug: Switch Thread→ 回车 → 选目标线程 - 切换后，
Variables和Call Stack立即刷新，但Watch表达式需重新求值 - 如果线程列表为空，说明 Worker 没成功 attach：检查
autoAttachChildProcesses是否生效、--inspect-brk是否传入、端口是否冲突
线程池场景下避免端口冲突和快速退出
批量创建 Worker 实例时，容易因调试端口复用或初始化过快导致附加失败。
- 每个 Worker 实例最好使用独立端口（如
--inspect-brk=9230、--inspect-brk=9231），或干脆不指定端口让 Node 自动分配（--inspect-brk不带等号） - Worker 入口加
parentPort?.postMessage('ready')，主线程用worker.once('message', () => { /* 继续执行 */ })等待就绪，防止调试器还没 attach 完 Worker 就跑完了 - macOS/Linux 下用 nvm 管理 Node 版本时，
runtimeExecutable必须显式设为nvm exec node或具体路径，否则子进程可能用错版本，autoAttachChildProcesses失效
最常被忽略的是：autoAttachChildProcesses 和 --inspect-brk 必须同时存在，缺一不可；而线程切换不是“自动发生”的动作，得手动触发——这两点卡住绝大多数人。
