NestJS应用Webpack打包报错：Logger依赖解析失败求助

问题本质 #

你遇到的这个报错，核心是Webpack代码压缩导致类名混淆，破坏了Nest依赖注入系统的令牌识别逻辑。当你在SecondService中使用new Logger(SecondService.name)时，Webpack默认的Terser压缩会把类名SecondService替换成r、s这类短标识符，而Nest的DI系统依赖原始类名来匹配依赖关系，最终抛出无法解析依赖的错误。

为什么FirstService没问题？ #

这大概率是Webpack优化策略的随机性导致的——FirstService的类名可能因为被其他代码的引用方式特殊，侥幸没被混淆；或者它的依赖链在打包时被完整保留，而SecondService的代码结构触发了Webpack的Tree Shaking或压缩规则，导致类名丢失。

解决方案 #

方案1：禁用类名压缩（快速临时修复）

修改你的Webpack配置，让TerserPlugin强制保留类名和函数名：

const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  // 其他配置项...
  optimization: {
    minimizer: [
      new TerserPlugin({
        terserOptions: {
          keep_classnames: true, // 保留类名不被混淆
          keep_fnames: true, // 保留函数名不被混淆
        },
      }),
    ],
  },
};

打包后类名会保持原样，Nest就能正确识别SecondService.name对应的令牌了。

方案2：改用Nest依赖注入获取Logger（符合框架规范）

直接实例化Logger虽然简单，但不符合Nest的DI设计理念，也容易碰到打包问题。推荐通过构造函数注入Logger：

import { Injectable, Logger } from '@nestjs/common';

@Injectable()
export class SecondService {
  private readonly logger: Logger;

  constructor(logger: Logger) {
    // 注入的Logger默认已关联当前类的上下文，无需手动指定name
    this.logger = logger;
    // 若要自定义上下文，也可以这样写：
    // this.logger = new Logger(SecondService.name);
  }
}

Nest会自动处理依赖解析，完全不受Webpack压缩的影响，这也是Nest官方推荐的用法。

方案3：调整Tree Shaking配置

如果你的Webpack开启了生产模式的Tree Shaking，可能会误删Nest依赖注入所需的装饰器元数据。可以在package.json中添加：

"sideEffects": ["*.ts", "*.js"]

或者在Webpack配置里设置：

module.exports = {
  // 其他配置项...
  optimization: {
    sideEffects: false,
  },
};

确保Nest的元数据不会被Tree Shaking误删。

验证方法 #

修改配置后，重新运行打包命令：

npm run bundle && node -e "require('./bundled/backend.js').handler()"

应该就能正常启动，不再抛出依赖解析错误了。

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