fastify 在 vscode 中断点失效的根本原因是 node.js 调试通道未打通，必须使用 node --inspect=0.0.0.0:9229 启动并配置 launch.json 为 "request": "attach" 模式，同时确保 outfiles 路径与 sourcemap 精确匹配。
Fastify 在 VSCode 里跑不起来、断点不生效、热重载失效——根本不是框架问题，而是 Node.js 调试通道没打通。必须手动启用 V8 Inspector 并用 attach 模式连接，否则 VSCode 就像在给断电的机器设断点。
node --inspect=0.0.0.0:9229 启动命令不能省、地址不能默认
Fastify 自身不启动调试器，全靠 Node.js 的 --inspect 参数暴露 V8 调试端口。漏掉它，VSCode 根本连不上进程。
- 别写
node --inspect src/index.ts：默认绑定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 时，必须加-w（watch）和完整--inspect：fastify start -w --inspect=0.0.0.0:9229 -l info src/index.ts
launch.json 必须用 "request": "attach"，不是 "launch"
Fastify 启动极快，launch 模式容易因时序问题错过断点——尤其配合 nodemon 或 ts-node-dev 时，VSCode 还没连上，进程已退出。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
-
"request": "attach"是唯一可靠方式：主动连接已运行的进程 -
"port": 9229必须和启动命令里的端口号完全一致（填成9228或9230就连不上） - 加
"restart": true：保存触发重启后，VSCode 自动重连 -
"address": "localhost"可省略（默认值），但别改成0.0.0.0—— 这是启动端口监听地址，不是调试连接地址
sourceMaps 和 outFiles 路径必须严丝合缝
断点打在 .ts 文件却停在 .js 上，或完全不触发，99% 是 sourcemap 映射失败。开关开了没用，关键看 outFiles 是否精准指向编译产物。
-
"sourceMaps": true只是总开关，真正起作用的是outFiles - tsc 编译项目：确认
tsconfig.json中"outDir": "dist"，则outFiles写成["${workspaceFolder}/dist/**/*.js"] - ts-node 项目：确保
tsconfig.json有"sourceMap": true或"inlineSourceMap": true - Windows 下路径用正斜杠
/，反斜杠\不被识别 - 排除
node_modules：默认会跳过，若需调试依赖内部逻辑，得清空"skipFiles"数组
Schema 验证断点要打在 preValidation 钩子里
在路由 handler 里打断点想看参数校验失败？大概率进不去——因为 Fastify 的 Schema 校验发生在 preValidation 钩子阶段，错误会在进入 handler 前就被拦截并返回 400。
- 想调试校验逻辑，断点必须放在
preValidation钩子函数内，例如：fastify.addHook('preValidation', (req, reply, done) => { /* 断点打这里 */ done() }) - handler 里只能看到校验通过后的数据；如果想观察原始请求体，可在
onRequest钩子中设断点 - 注意：
preValidation不会触发于未定义 schema 的路由，确保 route 配置了schema字段
三处配置——--inspect 地址、launch.json 的 port、outFiles glob 路径——差一个字符，断点就静默失效。没人帮你自动对齐，全靠手动核对。
