必须将断点移至prevalidation钩子，因为fastify的schema验证在prevalidation中执行，失败时直接返回400且不进入handler；可在路由内联或通过addhook注册该钩子，并确保调试配置（--inspect地址、port、sourcemap路径）正确匹配。
断点打在handler里看不到Schema验证失败？必须移到preValidation钩子
Fastify的Schema校验不是“经过handler时才触发”的逻辑，它默认在preValidation生命周期钩子中执行，并在验证失败时直接返回400响应、根本不会进入handler。你在handler函数里打的断点，99%情况下压根不会被触发——因为错误早被拦截了。
要调试Schema验证过程，断点必须放在preValidation钩子内部，或者用addHook显式注册：
fastify.addHook('preValidation', async (request, reply) => { /* 这里打断点 */ })- 或在路由定义里内联：
{ preValidation: async (req, rep) => { /* 断点放这 */ } } - 如果用了
fastify-swagger或fastify-json-schema等插件，确认它们没覆盖或禁用默认钩子链
VSCode连不上preValidation断点？检查--inspect地址和attach端口是否一致
即使钩子位置对了，断点仍不触发，大概率是调试通道根本没连通。Fastify不启动调试器，全靠Node.js的--inspect参数暴露V8 Inspector服务。
常见错误包括：
- 启动命令写成
node --inspect src/index.js（默认绑定localhost:9229），但VSCode运行在WSL/Docker里，无法访问localhost→ 改为node --inspect=0.0.0.0:9229 src/index.js -
launch.json里port填了9228或9230，和启动命令不匹配 → 必须严格一致 - 用了
fastify start -w但漏了--inspect=0.0.0.0:9229→ 热重载后新进程没调试能力
TypeScript项目断点停在.js文件？outFiles路径没对上编译产物
你打在src/routes/user.ts里的断点，结果停在dist/routes/user.js上，说明sourceMap映射失败。VSCode靠outFiles字段定位编译后的JS文件，不是靠tsconfig.json自动推导。
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
确认三件事：
-
tsconfig.json里有"sourceMap": true，且"outDir"设为"dist" -
launch.json中outFiles写成["${workspaceFolder}/dist/**/*.js"]（注意是正斜杠，Windows下反斜杠\无效） - 别写成
["**/*.js"]或["./dist/**/*.js"]——前者会扫到node_modules，后者路径解析失败
为什么Schema验证逻辑里加了console.log却没输出？检查是否被preHandler跳过
某些Fastify插件（比如fastify-caching或自定义preHandler钩子）可能提前终止请求流，导致preValidation根本没执行。这时console.log不打印，断点也不触发，容易误判为“Schema没生效”。
验证方式很简单：
- 临时删掉所有非核心插件，只留
fastify和你的路由定义，看断点是否恢复 - 在
preValidation钩子里加console.log('preValidation hit')，再发一个必错的请求（比如少传required字段） - 如果log没出现，说明钩子链被截断；如果出现了但没进handler，才是真正的Schema验证生效
真正难缠的是钩子执行顺序和插件间隐式覆盖——这种问题没法靠单个配置解决，得逐个禁用插件排查。
