Egg.js 中 Service 继承问题的分析与解决方案

问题背景

在 Egg.js 框架开发过程中，开发者经常会遇到需要继承框架提供的基类 Service 的情况。Service 作为 Egg.js 的核心概念之一，负责处理业务逻辑，通常需要访问应用实例(app)和上下文(context)等核心对象。

典型错误场景

当开发者尝试在自定义 Service 中直接继承 Egg.js 的 Service 基类时，可能会遇到以下错误：

TypeError: Cannot read properties of undefined (reading 'app')

这个错误表明框架无法正确初始化 Service 实例，因为基类 Service 的构造函数需要访问 this.app 属性，但在实例化过程中这个属性未被正确注入。

问题根源分析

1. Egg.js 的依赖注入机制：Egg.js 框架采用依赖注入模式管理组件，Service 实例的创建和依赖注入由框架控制

2. Tegg 模块的影响：当项目中使用 @eggjs/tegg 装饰器时，Service 的实例化过程与传统 Egg.js 有所不同

3. 构造函数参数缺失：基类 Service 需要特定的上下文参数，但直接继承时这些参数未被传递

正确解决方案

在结合 Tegg 模块使用时，推荐采用依赖注入的方式获取所需对象：

import { EggLogger, Context } from 'egg';
import { SingletonProto, AccessLevel, Inject } from '@eggjs/tegg';

@SingletonProto({
  accessLevel: AccessLevel.PUBLIC,
})
export class ArticlesService {
  @Inject()
  private readonly ctx: Context;

  @Inject()
  logger: EggLogger;

  async hello(userId: string): Promise<string> {
    // 通过 this.ctx.app 访问应用实例
    const app = this.ctx.app;
    return `hello, ${userId}`;
  }
}

技术原理详解

1. 依赖注入的优势：

   • 解耦组件关系
   • 提高代码可测试性
   • 实现按需加载

2. @Inject 装饰器作用：

   • 标记需要注入的属性
   • 支持类型推断
   • 延迟初始化依赖项

3. 上下文对象(Context)的作用：

   • 封装请求相关信息
   • 提供应用实例访问
   • 包含框架核心功能

最佳实践建议

1. 明确组件生命周期：根据业务需求选择合适的生命周期装饰器(@SingletonProto 或其它)

2. 合理设置访问级别：仅将必要的服务设置为 PUBLIC 访问级别

3. 日志记录规范：充分利用注入的 logger 进行规范的日志输出

4. 类型安全：充分利用 TypeScript 的类型系统，明确定义注入属性的类型

常见问题延伸

1. 多层级注入：当 Service 需要注入其它 Service 时，同样使用 @Inject 装饰器

2. 循环依赖处理：Egg.js 框架会自动处理大多数循环依赖情况

3. 测试策略：依赖注入使得单元测试时可以轻松 mock 依赖对象

通过理解 Egg.js 的依赖注入机制和正确使用 Tegg 模块提供的装饰器，开发者可以构建出结构清晰、易于维护的服务层代码。这种模式不仅解决了基类继承问题，还为应用提供了更好的可扩展性和可测试性基础。