fastify断点失效的根本原因是调试通道未连通，必须显式启用node --inspect=0.0.0.0:9229、配置vscode attach模式，并确保port、sourcemaps与outfiles路径三者严格一致。
Fastify 断点不生效，不是代码写错了，而是调试通道根本没连上——必须显式启用 node --inspect、用 attach 模式连接、且 sourceMaps 和 outFiles 路径三者严丝合缝。
怎么启动 Fastify 才能被 VSCode 连上调试器
Fastify 本身不启动调试器，全靠 Node.js 的 --inspect 参数。漏掉它，VSCode 就像对着关机的电脑设断点。
常见错误是只写 node --inspect src/index.js，这默认绑定 localhost:9229，在 WSL、Docker 或远程开发时 VSCode 根本连不上进程。
正确做法是显式指定监听地址和端口：
- TypeScript 项目：
node --inspect=0.0.0.0:9229 -r ts-node/register/transpile-only src/index.ts - JS 项目：
node --inspect=0.0.0.0:9229 src/index.js - 用
fastify startCLI：fastify start -w --inspect=0.0.0.0:9229 -l info src/index.ts（-w必须加，否则热重载不触发调试重连）
launch.json 为什么必须用 attach 而不是 launch
Fastify 启动极快，生命周期短，launch 模式容易因时序问题错过断点——尤其配合 nodemon 或 ts-node-dev 时，VSCode 还没连上，进程已经跑完并退出。
attach 是主动连接已运行的进程，可控性高，适合绝大多数 Fastify 开发流。
关键配置项不能错：
-
"request": "attach"（不是"launch"） -
"port": 9229（必须和启动命令里的端口完全一致，填错成9228或9230就连不上） -
"restart": true（让 VSCode 在进程重启后自动重连） -
"sourceMaps": true（开关，但真正起作用的是outFiles）
sourceMaps 映射失败？检查 outFiles 路径是否精准
断点打在.ts 文件却停在编译后的 .js 上，或完全不触发，基本是 sourcemap 映射失败。
outFiles 必须精准指向编译输出的 JS 文件位置，不能靠猜：
- 用
tsc编译：确认tsconfig.json中"outDir": "dist"，则outFiles写成["${workspaceFolder}/dist/**/*.js"] - 用
ts-node：确保tsconfig.json里"sourceMap": true或"inlineSourceMap": true - Windows 下反斜杠
\不被识别，统一用正斜杠/ - 别写成
**/*.js——太宽泛，VSCode 会找不到映射关系
想调试 Schema 验证逻辑？断点得放对钩子
Fastify 的 Schema 不是“自动生效”的魔法，校验发生在 preValidation 生命周期钩子中。
如果你在路由 handler 函数里打断点想看验证失败后的 error，大概率会错过——因为错误在进入 handler 前就被拦截并返回了 400。
正确做法：
- 在
preValidation钩子里设断点：fastify.addHook('preValidation', (req, reply, done) => { debugger; done(); }) - 或直接在
schema定义里加validate函数，断点打在里面 - 注意：
skipFiles默认排除node_modules，如果要进fastify内部源码调试，得显式设"skipFiles": []
--inspect 地址、launch.json 的 port、outFiles 的 glob 模式——断点就失效。最常被忽略的是启动时没加 --inspect=0.0.0.0:9229，而不是 --inspect。
