NestJS生产构建后报错：无法解析CheckService的CHECK_OPTIONS依赖

这个问题90%以上的场景是生产构建的代码压缩/混淆逻辑导致注入token不匹配，本地开发不会开启全量压缩，所以运行正常。常见的触发原因有3种：

1. 你定义CHECK_OPTIONS注入token时没有使用Nest官方的InjectionToken类，而是直接用普通字符串/const常量作为token，生产压缩时常量值被混淆，导致@Inject(CHECK_OPTIONS)的引用和模块里provider的provide值对应不上。
2. 你在某个模块导入CheckModule时，没有调用forRoot()方法，而是直接导入了静态的CheckModule类，生产构建的tree shaking逻辑把forRoot方法里定义的CHECK_OPTIONS提供者给清除了。
3. 你在多个文件里重复定义/导出了CHECK_OPTIONS常量，压缩后不同文件引用的是不同的变量实例，token匹配失败。

• 先查看CHECK_OPTIONS的定义代码，确认是不是通过@nestjs/common的InjectionToken创建的。
• 全局搜索项目中所有导入CheckModule的位置，确认是否全部调用了CheckModule.forRoot()方法，没有直接写imports: [CheckModule]的情况。
• 临时修改nx的生产构建配置，把optimization设置为false后打生产包，本地运行dist产物，如果不再报错就能100%确认是压缩混淆导致的问题。
• 检查CHECK_OPTIONS的导入路径，确认所有用到该token的地方都是从同一个路径导入的，没有相对路径写错导致引用了重复定义的token。

优先修复token定义（最常用方案） #

把CHECK_OPTIONS的定义改成标准的Nest注入token写法，就可以避免压缩混淆问题：

// check.constants.ts
import { InjectionToken } from '@nestjs/common';
import type { CheckOptions } from './interfaces/check-options.interface';

export const CHECK_OPTIONS = new InjectionToken<CheckOptions>('CHECK_OPTIONS');

InjectionToken内部会保留你传入的字符串标识，不会被生产压缩逻辑混淆，token匹配不会出问题。

修复模块导入逻辑 #

如果项目里有直接导入CheckModule的地方，统一改成调用forRoot：

// 根模块的imports配置
@Module({
  imports: [
    // 正确写法
    CheckModule.forRoot({ /* 你的配置 */ }),
    // 错误写法，要删掉
    // CheckModule
  ]
})
export class AppModule {}

如果需要在多个子模块导入CheckModule，可以给CheckModule加上@Global()装饰器，只需要在根模块注册一次，其他子模块不用重复导入。

特殊场景的压缩配置修复 #

如果修改完token还是有问题，可以在nx的project.json对应项目的构建配置里，加保留常量的配置，避免tree shaking清除token：

{
  "targets": {
    "build": {
      "configurations": {
        "production": {
          "optimization": true,
          "namedChunks": true,
          // 增加侧效配置，保留token文件
          "externalDependencies": "none",
          "outputHashing": "all"
        }
      }
    }
  }
}

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