ts-node运行Fastify时报Property 'foo'不存在于FastifyInstance类型错误

• 第一步：补全tsconfig的编译文件范围配置
  当前你贴出的tsconfig没有配置include和typeRoots字段，ts-node默认仅加载入口文件直接关联的依赖类型，不会主动扫描项目根目录下@types文件夹内的自定义声明文件，导致模块扩展的类型定义完全不被ts-node进程识别。
  解决方式：
  1. 在compilerOptions内添加typeRoots配置，明确指定类型声明的扫描路径：

     "typeRoots": [
       "./node_modules/@types",
       "./@types"
     ]
     

  2. 在compilerOptions同级添加include配置，将源码目录和自定义类型目录都纳入编译范围：

     "include": [
       "**/*.ts",
       "@types/**/*.d.ts"
     ]
     

• 第二步：修正自定义类型声明的合并逻辑
  你当前写的类型扩展手动重写了FastifyInstance的前3个泛型参数，但fastify实际导出的FastifyInstance接口是带4个泛型参数（最后一个为FastifyLoggerInstance）的，泛型参数数量不匹配会导致模块声明合并失效。
  不需要手动抄录原接口的全部泛型默认值，只需要在模块扩展内直接新增要声明的属性即可，修正后的@types/index.d.ts内容如下：

  import 'fastify';
  
  declare module 'fastify' {
    interface FastifyInstance {
      foo: {
        bar: string;
      };
    }
  }
  

  这种写法会自动继承原接口的所有泛型定义，不会出现泛型不匹配的问题。
• 第三步：检查ts-node的启动参数
  不要使用ts-node --transpile-only模式启动服务，该模式会完全跳过类型声明文件的加载，直接转译代码，导致自定义的扩展类型完全不生效，触发类型不存在的报错。
  如果需要提升启动速度，可以在启动命令中保留类型检查、仅跳过node_modules内的库文件检查，使用命令：

  ts-node --compiler-options '{"skipLibCheck": true}' server.ts
  

• 第四步：验证路由内的this上下文类型
  确保路由回调是普通async函数而非箭头函数，这样Fastify才能正确把实例上下文绑定到函数的this上，配合扩展的类型定义完成this.foo的类型推导。

内容的提问来源于stack exchange，提问作者junep