vscode调试node.js worker threads必须启用autoattachchildprocesses并为worker显式传入--inspect-brk参数，否则断点不命中；esm项目还需确保worker上下文模块类型一致。
VSCode调试Node.js子线程（Worker Threads）必须启用 autoAttachChildProcesses，否则断点永远不进Worker文件——这不是“没写对”，而是调试器压根没尝试连接。
为什么Worker断点不命中？autoAttachChildProcesses 是硬开关
VSCode默认只调试 launch.json 中 program 指向的主进程。Worker是独立V8实例，不共享调试会话，也不继承主进程的 --inspect 参数。只有把 "autoAttachChildProcesses": true 显式写进 launch 配置，vscode-js-debug 才会在主进程启动后监听 new Worker() 调用，并主动尝试附加。
-
autoAttachChildProcesses对spawn()无效，只响应fork()和Worker构造函数 - 它不是“建议开启”，而是子线程调试的必要前提；设为
false或漏掉，Worker 就彻底脱离调试链路 - 若项目用
ts-node或esbuild-node启动主进程，该配置会静默失效——它们绕过标准 Node 启动流程，无法触发子进程监听
--inspect-brk 必须传给 Worker 实例，不能只配在主进程
Worker 默认不暴露调试端口。即使 autoAttachChildProcesses 开启了，如果 Worker 启动时没带 --inspect-brk，VSCode 就找不到可连接的目标。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 正确写法：
new Worker('./worker.js', { execArgv: ['--inspect-brk=9229'] }) -
execArgv是唯一能控制 Worker 进程启动参数的字段；argv或env都不管用 - 端口号必须和 launch.json 中的
port字段一致（如"port": 9229），否则附加失败 - 多个 Worker 共用同一端口会导致仅第一个被附加；更稳妥的做法是删掉
=9229，让 Node 自动分配（['--inspect-brk']），VSCode 仍能捕获
ESM项目中Worker调试失败？检查模块解析一致性
ESM 下 new Worker('./worker.js') 容易报错或断点失效，根本原因是 Node 默认按 CommonJS 解析 Worker 路径，而 package.json 的 "type": "module" 不自动透传到 Worker 上下文。
- 确保 Worker 文件所在目录也有
package.json，且同样声明"type": "module" - 路径不能用
file://协议前缀；Worker 构造函数只接受相对路径或data:URL - 若 Worker 里用了
import但主进程是 CJS，可能因模块解析错位导致加载失败——此时断点不命中其实是进程根本没起来 - 临时验证方式：在 Worker 开头加
console.log(process.argv)，确认--inspect-brk确实出现在参数里
调试卡顿、CPU飙升？autoAttachChildProcesses 不是万能开关
高频创建 Worker（比如每秒几十个）时，autoAttachChildProcesses: true 会让 VSCode 为每个实例建立调试代理，内存和 CPU 开销剧增，甚至拖垮整个调试会话。
- 开发阶段可保留该配置；生产或性能敏感场景应设为
false，改用手动 attach：Worker 启动时加--inspect=9230，再新增一个 attach 配置 - 搭配
"skipFiles": ["<node_internals>/**"]</node_internals>可减少底层代码干扰，但不影响子进程附加逻辑 - 若 Worker 仅用于计算、无须单步调试，考虑关闭调试支持，用
console.time()+ 日志定位瓶颈更轻量
真正麻烦的从来不是配多少字段，而是理解每个字段生效的前提条件：autoAttachChildProcesses 依赖标准 Node 启动流程，--inspect-brk 必须由 Worker 自己声明，ESM 模块系统必须两端对齐——少一个环节，调试就断在看不见的地方。
