Nest.js生产模式下跨模块服务调用报方法不存在的排查与解决

这类开发环境运行正常、生产打包后提示类方法不存在的报错，是Webpack打包NestJS生产产物时的高频问题，大量开发者都遇到过，常见触发原因包括：

• forwardRef的滥用问题
  项目没有形成循环依赖闭环时，强行给跨模块注入添加@Inject(forwardRef())装饰器，会在Webpack生产模式代码压缩、类名混淆阶段干扰依赖注入容器的实例解析，最终拿到的对象不是完整的ModelsService类实例，自然无法访问类原型上的挂载方法。
• Webpack配置缺陷导致的解析异常
  从给出的配置中可以发现几处明确错误：
• resolve.extensions数组第一项遗漏了开头的点，写法为"css"而非".css"，会破坏模块解析的优先级逻辑
• 配置中重复定义了两次output字段，后续定义的publicPath: "/"会直接覆盖前一段配置中正确的输出路径、文件名设置，造成产物结构混乱
• ts-loader未开启生产环境下的装饰器元数据保留，代码压缩过程中可能抹除类方法的挂载信息
• 循环依赖的不规范实现
  若确实存在双向依赖的循环场景，只在服务类的注入端单独使用forwardRef，没有在模块的导入端做对应声明，会直接导致实例解析失败。

1. 服务提供方模块正确导出依赖
   当前ModelsModule的写法符合规范，通过exports: [ModelsService]将服务暴露给所有导入该模块的上层模块，这部分无需调整。
2. 服务消费方直接构造函数注入，删除多余的forwardRef
   当前AppModule与ModelsModule不存在双向依赖的循环闭环，完全不需要使用forwardRef语法，修改AppService的构造函数即可：

   @Injectable()
   export class AppService {
     constructor(
       // 移除多余的@Inject(forwardRef(() => ModelsService))装饰器
       private readonly modelsService: ModelsService,
     ) {}
   }
   

3. 修正Webpack配置的错误项
   • 合并重复的output配置，将所有输出规则统一到同一个配置对象下：

     output: {
       filename: 'serverBundle.js',
       path: path.resolve(__dirname, 'dist/static/server'),
       publicPath: "/"
     }
     

   • 修正resolve.extensions的格式，补全所有后缀开头的点：

     resolve: {
       modules: [__dirname, 'node_modules'],
       extensions: [".css", ".ts", ".tsx", ".scss", ".js", ".json"]
     }
     

   • 为ts-loader补充装饰器元数据保留配置，避免生产压缩时丢失类方法信息：

     {
       test: /\.ts(x?)$/,
       exclude: /node_modules/,
       use: {
         loader: 'ts-loader',
         options: {
           compilerOptions: {
             emitDecoratorMetadata: true
           }
         }
       }
     }
     

4. 若确实存在必须使用forwardRef的循环依赖场景，需要在模块导入端和服务注入端双向配合使用forwardRef，不能只在单端声明。

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