Worker断点不命中根本原因是其默认不暴露调试端口，必须显式传入--inspect-brk参数并确保launch.json中port与execArgv端口一致，且启用autoAttachChildProcesses:true；ts-node或esbuild-node会绕过标准启动链导致该配置失效。
VSCode调试Worker Threads时断点不命中
根本原因是Worker默认不暴露调试端口，即使启用了autoAttachChildProcesses: true，VS Code也找不到可连接的调试器。必须显式传入--inspect-brk参数，并确保端口一致。
- 在创建Worker时，必须带
execArgv：new Worker('./worker.js', { execArgv: ['--inspect-brk=9229'] }); -
launch.json中对应主进程配置需包含："runtimeArgs": ["--inspect-brk"]、"port": 9229、"autoAttachChildProcesses": true - 多个Worker共用同一端口会导致只连上第一个——要么为每个Worker分配唯一端口（如
9230、9231），要么干脆不指定端口让Node自动分配（删掉=9229） - 若用
ts-node或esbuild-node启动主进程，autoAttachChildProcesses会失效——它们绕过了标准Node启动链，此时应改用node --loader ts-node/esm模式
child_process.fork()子进程无法被VS Code附加
不是VS Code没识别到子进程，而是fork()本身没启动调试能力。它不像Worker那样自动继承父进程调试参数，必须手动透传。
- 调用
fork()时务必传execArgv：fork('./child.js', [], { execArgv: ['--inspect-brk=9230'] }); -
spawn()不被autoAttachChildProcesses自动捕获——除非你手动加--inspect-brk参数，否则它完全不会出现在调试器视野里 - macOS/Linux下用nvm管理Node版本时，子进程可能沿用系统默认Node而非nvm当前版本——必须在
launch.json中显式写"runtimeExecutable"路径，否则父子进程Node版本不一致会导致调试失败
launch.json里runtimeExecutable该不该写死
写死路径看似稳妥，实则破坏协作和可移植性；但完全不写又容易在nvm/volta环境里掉坑。关键看场景。
- 团队项目、CI环境、或多人共用同一代码库时，不要硬编码
runtimeExecutable——它会让别人拉代码后立刻报错 - 本地开发且明确需要某版本（比如Node 18跑旧版Worker API），优先用终端启动VS Code：
nvm use 18.19.1 && code .，再依赖默认查找逻辑 - 只有在容器、WSL、Electron内嵌Runtime等特殊运行时才显式指定
runtimeExecutable，且路径必须是绝对路径（~会被忽略） -
runtimeVersion字段（VS Code 1.85+）仅作校验提示，不会自动切换版本——别指望它帮你解决兼容性问题
为什么开了autoAttachChildProcesses还是看不到子进程调用栈
能连上≠能联动。附加成功只是第一步，跨进程上下文调试还依赖source map对齐和模块加载方式。
- 子进程的
.js和.js.map必须在同一目录，且sourceMap: true在tsconfig.json中开启——否则断点位置错乱，VS Code显示“已停在未加载脚本” - ESM环境下，Worker构造函数不支持
import()动态加载带source map的模块——改用new Worker(new URL('./worker.js', import.meta.url))保证路径解析正确 - 如果子进程用
require('worker_threads').Worker但入口是TS文件，必须确保编译产物保留原始路径映射，否则VS Code无法将断点映射回源码行
