worker 中断点无效的根本原因是调试器未附加子线程，需在 launch.json 中启用 autoattachchildprocesses: true、worker 初始化时传入 execargv 启用 --inspect-brk，并确保 sourcemap 正确映射且手动切换至 worker 线程上下文。
断点拦不住 Worker 里的 parentPort.postMessage() 或 workerPort.postMessage()？不是代码问题，是调试器根本没进线程上下文。
为什么主线程断点有效，Worker 里却跳过
VS Code 默认只 attach 主线程。即使你写了 new Worker('./worker.js')，只要 launch.json 没开 autoAttachChildProcesses，Worker 就在“隐身模式”运行——断点变空心圆，console.log 可能被吞，postMessage 调用完全不暂停。
-
autoAttachChildProcesses: true是硬性开关，不是可选项；仅靠--inspect或--inspect-brk不足以触发附加 - Worker 构造时若没传
execArgv，Node 不会暴露调试端口，VS Code 就连不上它 - 路径写成
./worker.js容易因process.cwd()变化导致解析失败，断点绑定不到源码
确保 postMessage 断点能停住的三步实操
让 parentPort.postMessage() 和 workerPort.postMessage() 真正停住，得同时满足：子进程可见、源码可映射、线程可切换。
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 在
launch.json的 Node 配置里明确加："autoAttachChildProcesses": true，并配"runtimeArgs": ["--inspect-brk"] - Worker 初始化必须带调试参数：
new Worker('./worker.js', { execArgv: ['--inspect-brk=9230'] })（端口要与launch.json中port一致，或干脆不指定端口让 Node 自选） - Worker 文件路径用
path.resolve(__dirname, 'worker.js')，避免相对路径歧义；确认该文件在工作区根目录下，没被files.exclude或.gitignore隐藏
断点命中后怎么看到消息内容和通信流向
断点停住了，但变量面板里看不到 message 或 data？这不是通信出错，而是你还在主线程上下文里看 Worker 的堆栈。
- 右上角调试工具栏的线程下拉框必须展开，里面应有
Main Thread和类似Worker Thread #1的条目 - 不要靠鼠标点选——快捷键
Ctrl+Shift+P→ 输入Debug: Switch Thread→ 回车 → 选目标 Worker 线程，更可靠 - 切换后，
Call Stack和Variables面板立刻刷新；Debug Console作用域也同步切换，可直接输入message查值 - 如果用了
transferList发送ArrayBuffer，注意它传输后在原线程变为null，别在错误线程查
sourceMap 失效导致 postMessage 断点空心圆
Worker 文件是 TypeScript 编译来的？或者用了 esbuild 打包？那空心圆大概率是 source map 没对上。
-
tsconfig.json必须含"sourceMap": true和"inlineSources": true（后者让源码嵌入 map，避免路径错乱） -
launch.json对应配置里加："sourceMaps": true和"outFiles": ["./dist/**/*.js"]（路径按实际输出调整） - 构建命令必须先跑完，确保
worker.js.map和worker.js在同一目录；检查 map 文件里sources字段是否指向原始.ts路径
真正卡住的从来不是 postMessage 本身，而是调试器没进线程、没读到源码、或者你没手动切过去——这三道关漏掉任意一个，断点就只是个红点而已。
