NestJS配置文件上传拦截器时访问req.user._id报TS类型错误

TypeScript的静态类型校验和JS运行时特性是两套逻辑：

• 运行时阶段你能从req.user上打印出_id字段，说明对象本身实际是存在这个属性的，JS动态取值不会卡这个。
• 编译阶段TS报错，是因为当前代码给req.user绑定的User类型定义里，根本没有声明_id这个属性，TS只认你写的类型定义，不认运行时实际存在的字段，所以直接访问就会抛出TS2339错误。

1. 补全全局User类型定义 #

找到项目里被关联到req.user的那个User接口/类定义，把实际JWT返回的所有字段补进去：

// 补全后的User类型示例
interface User {
  _id: string;
  status: 'active' | 'disabled';
  iat: number;
  exp: number;
  // 其余业务字段按需补充
}

如果是通过全局扩展Express Request类型实现的req.user类型绑定，要确保扩展代码里的类型引用指向补全后的User定义：

declare global {
  namespace Express {
    interface Request {
      user: User
    }
  }
}

改完之后全局所有访问req.user._id的位置都不会再触发类型报错。

2. 局部类型断言（适配单文件临时场景） #

如果只是当前上传接口需要访问这个字段，不想改动全局类型定义，可以在使用位置做精准的类型断言，不要直接断言成any：

destination: (req, file, cb) => {
  // 定义当前场景用到的JWT负载结构
  interface JwtAuthPayload {
    _id: string;
    status: string;
    iat: number;
    exp: number;
  }
  // 做类型转换，绕开不匹配的旧类型
  const usern = req.user as JwtAuthPayload;
  console.log(usern._id); // 编译正常通过
  // 原有目录创建逻辑保持不变
}

• 尽量不要写req.user as any的暴力断言，这种写法会完全绕过TS的字段校验，后续如果字段名拼写错误、字段缺失，编译阶段完全不会提示，很容易引入线上问题。
• 如果用的是Passport JWT鉴权策略，记得把策略validate方法的返回值结构和你定义的User类型做对齐，避免出现类型定义和实际返回字段不匹配的问题。

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