NestJS中Auth与User模块出现循环依赖的最佳处理实践问询

方案1：依赖倒置抽离公共接口（最符合架构规范） #

• 新增独立的公共接口层，可放在项目shared/interfaces目录下，分别声明IUserService、IAuthService核心方法接口
• Auth模块仅依赖IUserService接口，User模块仅依赖IAuthService接口，具体实现类通过依赖注入容器在启动时动态注入，不需要直接导入对方的实体模块，从结构上解除循环引用
• 以下为TypeScript场景示例：

// shared/interfaces/auth.interface.ts
export interface IAuthService {
  generateJwt(userId: string, payload?: Record<string, any>): Promise<string>;
}

// shared/interfaces/user.interface.ts
export interface IUserService {
  createUser(userInfo: CreateUserDto): Promise<UserEntity>;
  getUserById(userId: string): Promise<UserEntity>;
}

模块注册时仅绑定接口与对应实现类的映射关系，不需要导入对方的模块实体。

方案2：无状态能力下沉到公共工具层 #

• 若JWT生成逻辑仅涉及签名、有效期设置这类无状态操作，可将这部分逻辑抽离为独立的JwtUtil工具类，归属于全局公共工具模块
• Auth模块和User模块都直接依赖公共工具模块的JwtUtil，User Controller需要生成JWT时直接调用工具类方法即可，不需要引用Auth Service
• 注意JWT校验、黑名单管理、刷新Token存储这类和鉴权业务强绑定的逻辑仍保留在Auth Service中，仅抽离无状态的通用生成逻辑。

方案3：调整业务接口归属（优先推荐） #

• 天然需要返回JWT的用户操作接口（比如注册、登录）本身属于鉴权业务域，可直接迁移到Auth Controller中实现
• Auth Service调用User Service完成用户表读写操作后，直接生成JWT返回，User模块不再需要依赖Auth模块，完全符合所有用户表操作都走User Service的设计原则，后续维护成本最低。

方案4：框架原生兼容（临时补救） #

• 若迭代周期紧张可先使用依赖注入框架提供的延迟加载能力临时解决问题：NestJS可使用@Inject(forwardRef(() => AuthService))声明注入，Spring可使用@Lazy注解延迟加载Bean
• 注意：该方案仅为临时补救手段，长期使用会提升代码排查、单元测试的复杂度，后续迭代需要尽快通过业务拆分彻底解决循环依赖

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