结论先行
- 首选方案：Web API/HTTP 服务使用 Egg.js + Tegg。Egg 负责“传输层与工程化”，Tegg 负责“模块化/DI/生命周期/可测试性”。生态完善、上手快、上线稳。
- 仅用 Tegg：适合“非 HTTP 的后台任务/Worker/脚本/领域层库”，或明确不需要 Egg 的 Web/插件/进程模型时。
如何判断（决策清单）
- 是否需要：路由与中间件、参数校验、安全（CSRF/CORS）、多进程 app/agent 模型？需要 → 选 Egg + Tegg。
- 是否需要：成熟的配置体系、插件生态（如 MySQL/Redis/鉴权/监控）、日志与异常处理？需要 → 选 Egg + Tegg。
- 服务形态：对外 HTTP/网关/API？是 → 选 Egg + Tegg；纯离线/消费任务 → 可仅用 Tegg。
- 团队经验：对 Egg 熟悉度高？是 → Egg + Tegg 落地更快。
- 复杂性需求：强 DI、可替换实现、多实例/多租户？有 → 两者都行；但结合 Tegg 能获得更清晰依赖图与更高可测性。
使用 Egg.js + Tegg 的典型场景
- 绝大多数 Web/HTTP 服务（REST/GraphQL/gRPC 网关），需要中间件、鉴权、限流、灰度、观测。
- 需要丰富插件生态与约定式工程化脚手架，快速搭建、平滑迭代、稳妥运维。
- 对复杂业务做模块化、可替换实现，配合 AOP/DAL/ORM/Schedule/AJV 等装饰器生态进行统一治理。
仅用 Tegg 的典型场景
- 后台 Worker、消息消费、批处理、定时脚本，不需要 Web 层。
- 领域层/业务模块沉淀为可复用库，可在 Egg 或其他运行环境复用。
- 极简 HTTP 服务：自行选 Koa/Fastify 等做薄适配，并手接日志/配置/异常处理（灵活但基础设施要自建）。
运维与生产建议
- Egg + Tegg：省去大量基础设施接线（日志、配置、进程守护、健康检查、优雅关闭），更适合直接上生产。
- 纯 Tegg：需自选并接好 Web/进程/监控栈（或无需 Web），适合对基础设施有自定义诉求或非 HTTP 形态。
性能与复杂度
- Tegg 的 DI/元数据开销相对 Egg 的基础开销可忽略；换来更清晰依赖关系、更低长期维护成本。
- 纯 Tegg 的复杂度主要在你要自建的基础设施上，而非 Tegg 本身。
推荐落地路径（多数团队）
- 用 Egg.js 搭好应用骨架与运维体系；
- 引入 @eggjs/tegg-plugin，将核心业务服务逐步改造成 Tegg 模块（@Inject/@Lifecycle 等）；
- 按需引入 AOP/DAL/ORM/Schedule/AJV 装饰器生态，利用限定符管理多实现/多数据源；
- 对于非 HTTP 的任务进程，也可在独立进程中复用同一套 Tegg 模块。