VSCode调试Fastify必须用attach模式并配--inspect=0.0.0.0:9229启动，launch模式因时序问题易失败；outFiles路径须与tsc输出位置严格一致，端口需匹配，且需启用sourceMap。
VSCode 调试 Fastify 服务不是配完 launch.json 就能断点的——node --inspect=0.0.0.0:9229 启动命令漏掉，断点就永远静默跳过；用 launch 模式而不用 attach，热重载一重启，断点全失效。
Fastify 必须用 attach 模式 + --inspect=0.0.0.0:9229 启动
Fastify 启动极快，生命周期短，launch 模式常因时序问题错过 attach 时机。尤其配合 -w（watch）或 ts-node-dev 时，进程可能已执行完毕，VSCode 还没连上。
-
fastify start -w --inspect=0.0.0.0:9229 -l info src/index.ts是 TypeScript 项目最稳的 CLI 启动方式 - 别写成
--inspect（默认绑定localhost），WSL、Docker 或远程开发时 VSCode 会连不上 - 若用
ts-node直接运行，改用：node --inspect=0.0.0.0:9229 -r ts-node/register/transpile-only src/index.ts - 确保
tsconfig.json中"sourceMap": true已启用
launch.json 的 port / outFiles / request 三者必须严丝合缝
VSCode 断点打不进源码，90% 是 outFiles 路径没对上编译输出位置，或端口与启动命令不一致。
-
"request": "attach"—— 不是"launch"，这是强制要求 -
"port": 9229—— 必须和启动命令中--inspect=:9229的端口号完全一致（常见填错为 9228、9230） -
"outFiles": ["${workspaceFolder}/dist/**/*.js"]—— TypeScript 项目必须精准匹配tsc输出路径；不能写成**/*.js或./dist/**/*.js（Windows 下./会导致解析失败） - 加
"restart": true，这样保存文件触发热重载后，VSCode 会自动重连调试器
Schema 验证逻辑里断点不触发？检查 preValidation 钩子位置
Fastify 的 Schema 校验发生在进入路由 handler 之前，错误直接返回 400，根本不会走到你的 async (request, reply) => { ... } 里。
- 想调试校验过程，断点必须打在
preValidation钩子中，而不是 handler 内部 - 全局注册：
fastify.addHook('preValidation', (request, reply, done) => { /* 在这里打断点 */ }) - 单路由注册需显式声明：
preValidation: (req, res, done) => { /* 打断点 */ } - 注意：此时
request.body和request.query已解析，但尚未经过 Schema 校验
Node.js 环境没配好，VSCode 内置终端也跑不了 node
VSCode 调试 Fastify 前，先确认终端里 node -v 和 npm -v 可用。否则所有后续配置都白搭。
- Windows：检查系统环境变量
Path是否包含 Node.js 安装目录（如C:\Program Files\nodejs\） - macOS/Linux：运行
which node看是否有输出；确认~/.zshrc或~/.bash_profile里有类似export PATH="/usr/local/bin:$PATH"的语句 - VSCode 启动前要关掉再重开，否则读不到新
PATH（尤其 macOS GUI 启动的 VSCode）
真正容易被忽略的是：outFiles 路径必须和实际 JS 输出位置一字不差，哪怕多一个 ./ 或少一个 dist/，sourceMap 就断链，断点就失效。这不是“差不多就行”的事，而是字面级匹配。
