ts-node-dev调试必须用--inspect-brk并配置request:"attach"，因--inspect-brk使进程首行暂停等待连接，而launch模式与ts-node-dev重启机制冲突；runtimeExecutable设为node，runtimeArgs含--inspect-brk、-r、ts-node/register（顺序不可错），port需匹配，且需启用sourceMap相关tsconfig配置。
ts-node-dev 启动命令必须带 --inspect-brk
不加 --inspect-brk，VSCode 就连不上调试端口，断点永远不触发。它和 --inspect 不同：前者让 Node 进程在第一行就暂停、等待调试器连接；后者只是开启调试端口，进程直接跑起来，容易错过入口逻辑。
常见错误是只写 ts-node-dev src/index.ts 或漏掉 -r ts-node/register，结果报 Cannot find module 'xxx' 或断点灰显。
-
runtimeExecutable必须设为node（不是ts-node-dev），否则 VSCode 无法接管进程生命周期 -
runtimeArgs要包含：--inspect-brk、-r、ts-node/register——顺序不能错，-r和模块路径必须紧挨着 - 如果项目启用了 ESM（
"type": "module"），把-r ts-node/register换成--loader=ts-node/esm，且确保 Node ≥18.12
launch.json 里 request 必须是 attach，不是 launch
request: "launch" 会让 VSCode 自己拉起一个新进程，但 ts-node-dev 是靠文件监听 + 进程重启工作的，两者冲突。用 launch 模式，VSCode 启动后 ts-node-dev 才刚 fork 出子进程，断点早被跳过了。
正确做法是先手动启动 ts-node-dev，再让 VSCode 主动 attach 上去——这就是为什么 request: "attach" 更稳。
-
port值必须和启动命令里的--inspect-brk=9229一致（默认是 9229，别写成 9228 或 0.0.0.0:9229） - 加
"restart": true，这样每次ts-node-dev重启子进程后，VSCode 会自动重连，不用手动点“重新连接” -
"address": "localhost"就够了，除非你在 WSL/Docker 里调试，才需要改成0.0.0.0
sourceMaps 映射失效？检查 tsconfig.json 两个关键项
ts-node-dev 是内存转译，不生成 .js 文件，所以 outFiles 字段对它无效；但它依赖 tsconfig.json 中的解析能力来定位源码位置。断点打在 .ts 上却停在 .js 行、或直接不触发，八成是路径解析失败。
-
"moduleResolution": "node"或"node16"必须显式设置，否则@/utils这类路径别名无法解析 -
"resolveJsonModule": true必须开，否则import pkg from './package.json'会报错，进而导致ts-node-dev初始化失败 -
"baseUrl"和"paths"可以写，但ts-node-dev不做路径重写，只读配置；确保tsconfig.json在项目根目录且语法合法，否则它会静默降级为默认行为
断点重连失败？优先确认 TypeScript 版本一致性
VSCode 右下角显示的 TypeScript 版本，只影响编辑器内的语法提示和跳转；而 ts-node-dev 运行时完全依赖 node_modules 里的 typescript 包。两者版本不一致，就会出现“编辑器里没红波浪线，一调试就 TS2307 找不到模块”。
最直接的修复方式：右下角点击 TypeScript 版本号 → 选 Use Workspace Version，然后按 Ctrl+Shift+P → 输入 TypeScript: Restart TS server。
顺手检查两件事：
- 项目是否已安装
typescript和ts-node：npm install --save-dev typescript ts-node @types/node - 改过
tsconfig.json后没重启 TS Server，旧缓存会导致 sourcemap 映射错位，断点偏移一行甚至跳到空行
冷启动快不快，取决于 Node 启动速度和 ts-node-dev 的缓存命中率；但断点能不能重连上，核心就卡在这几个配置和版本对齐上——少一个，都得重配。
