> ## Documentation Index
> Fetch the complete documentation index at: https://tegg.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 开发 Node 服务：选择 Egg.js + Tegg，还是直接用 Tegg？

## 结论先行

1. 首选方案：Web API/HTTP 服务使用 Egg.js + Tegg。Egg 负责“传输层与工程化”，Tegg 负责“模块化/DI/生命周期/可测试性”。生态完善、上手快、上线稳。
2. 仅用 Tegg：适合“非 HTTP 的后台任务/Worker/脚本/领域层库”，或明确不需要 Egg 的 Web/插件/进程模型时。

## 如何判断（决策清单）

1. 是否需要：路由与中间件、参数校验、安全（CSRF/CORS）、多进程 app/agent 模型？需要 → 选 Egg + Tegg。
2. 是否需要：成熟的配置体系、插件生态（如 MySQL/Redis/鉴权/监控）、日志与异常处理？需要 → 选 Egg + Tegg。
3. 服务形态：对外 HTTP/网关/API？是 → 选 Egg + Tegg；纯离线/消费任务 → 可仅用 Tegg。
4. 团队经验：对 Egg 熟悉度高？是 → Egg + Tegg 落地更快。
5. 复杂性需求：强 DI、可替换实现、多实例/多租户？有 → 两者都行；但结合 Tegg 能获得更清晰依赖图与更高可测性。

## 使用 Egg.js + Tegg 的典型场景

1. 绝大多数 Web/HTTP 服务（REST/GraphQL/gRPC 网关），需要中间件、鉴权、限流、灰度、观测。
2. 需要丰富插件生态与约定式工程化脚手架，快速搭建、平滑迭代、稳妥运维。
3. 对复杂业务做模块化、可替换实现，配合 AOP/DAL/ORM/Schedule/AJV 等装饰器生态进行统一治理。

## 仅用 Tegg 的典型场景

1. 后台 Worker、消息消费、批处理、定时脚本，不需要 Web 层。
2. 领域层/业务模块沉淀为可复用库，可在 Egg 或其他运行环境复用。
3. 极简 HTTP 服务：自行选 Koa/Fastify 等做薄适配，并手接日志/配置/异常处理（灵活但基础设施要自建）。

## 运维与生产建议

1. Egg + Tegg：省去大量基础设施接线（日志、配置、进程守护、健康检查、优雅关闭），更适合直接上生产。
2. 纯 Tegg：需自选并接好 Web/进程/监控栈（或无需 Web），适合对基础设施有自定义诉求或非 HTTP 形态。

## 性能与复杂度

1. Tegg 的 DI/元数据开销相对 Egg 的基础开销可忽略；换来更清晰依赖关系、更低长期维护成本。
2. 纯 Tegg 的复杂度主要在你要自建的基础设施上，而非 Tegg 本身。

## 推荐落地路径（多数团队）

1. 用 Egg.js 搭好应用骨架与运维体系；
2. 引入 @eggjs/tegg-plugin，将核心业务服务逐步改造成 Tegg 模块（@Inject/@Lifecycle 等）；
3. 按需引入 AOP/DAL/ORM/Schedule/AJV 装饰器生态，利用限定符管理多实现/多数据源；
4. 对于非 HTTP 的任务进程，也可在独立进程中复用同一套 Tegg 模块。