根本原因是node环境未对齐：vitest默认用node进程运行测试，但fastify依赖模块（如fastify、ts-node）未正确加载或路径解析失败；需确保vitest和fastify同在devdependencies，vitest.config.ts设environment: 'node'，且app.ready()必须await后才能调用app.inject()。
VSCode里跑Vitest测试Fastify服务，为什么test不执行？
根本原因不是Vitest没装好，而是Node环境没对齐——Vitest默认用node进程运行测试，但Fastify服务依赖的模块（比如fastify、ts-node）可能没被正确加载或路径解析失败。
- 确保
vitest和fastify都在devDependencies或dependencies里，别只装在devDependencies却在test脚本里require生产级模块 - 如果用TypeScript，
vitest.config.ts里必须设environment: 'node'，否则它会按jsdom环境初始化，require('fastify')直接报错 - 常见错误：
Error: Cannot find module 'fastify'——检查node_modules是否真有该包，别被pnpm的硬链接或npm的workspace隔离搞懵
Vitest中app.inject()返回空响应或超时？
app.inject()本质是内存内HTTP模拟，不走真实网络栈，但它依赖Fastify实例已调用ready()。没等就发请求，结果就是空body或Promise卡住。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 必须在
beforeAll里await app.ready()，不能只await app.listen()（后者启动真实服务器，测试里不需要） - 别在
it块里重复app.get()注册路由——Fastify不允许热重载路由，第二次注册会静默失败或抛Duplicate route - 超时问题：Vitest默认timeout是5s，Fastify插件加载慢（比如带数据库连接）时，得显式加
timeout: 10000到it或describe配置里
断点打在app.get()回调里却不触发？
不是Vitest没调试支持，而是VSCode根本没连上Vitest启动的Node子进程。Vitest默认fork新进程跑测试，VSCode的调试器只attach主进程。
- 启动命令改用
vitest --inspect-brk（注意是--inspect-brk不是--inspect），它会让子进程停在第一行等调试器接入 -
launch.json里"request": "attach"+"port": 9229，和启动命令端口严格一致；别用launch模式，Vitest进程生命周期太短，VSCode来不及attach - TypeScript项目必须配
sourceMaps: true和精准outFiles，例如"outFiles": ["${workspaceFolder}/dist/**/*.js"]，否则断点停在编译后代码而非.ts源文件
Mock外部依赖（如数据库）后，app.inject()仍走真实调用？
Fastify插件加载顺序决定了mock生效时机。如果你在app.register()之后才vi.mock()，那插件内部require的模块早已缓存，mock无效。
- mock必须写在
import语句之后、app = Fastify()之前，且用vi.mock('./db', () => ({ query: vi.fn() }))这种内联写法 - 避免在
beforeEach里mock——它发生在app实例创建之后，此时插件已加载完毕 - 验证mock是否生效：在测试里
console.log(require('./db').query)，输出[Function mockConstructor]才算成功
await app.ready()，或launch.json里端口差一位数，断点就彻底失联。
