审查 NestJS 代码变更时如何系统化检查模块、DI…

在合并 PR、实现新功能或做架构校验时，对 NestJS 应用的控制器、服务、模块、守卫、拦截器、管道、依赖注入和数据库集成进行结构化代码审查。

适用场景

解决思路

1. 确定审查范围：用 glob 和 grep 找出目标区域内所有 controllers、services、modules、guards、interceptors、pipes，明确本次审查涉及哪些文件和模块。
2. 分析模块结构：验证每个功能拥有独立 module，且 imports、controllers、providers、exports 定义清晰；检查是否存在循环依赖以及模块边界是否合理。
3. 审查依赖注入：确认所有可注入服务都使用构造函数注入；检查 provider 作用域（singleton、request、transient）是否与预期生命周期一致；确保没有直接实例化绕过 DI 容器。
4. 评估控制器：检查 HTTP 方法使用、路由命名、状态码、请求/响应 DTO、验证管道和 OpenAPI 装饰器；确认控制器保持轻薄，业务逻辑应放在 service 中。
5. 评估服务与业务逻辑：确认 service 正确封装业务逻辑，检查错误处理、事务管理以及与基础设施关注点的分离；找出过大或职责过多的 service 方法。
6. 检查安全性：审查 guard 实现、认证/授权模式、使用 class-validator 的输入验证，以及对常见漏洞（注入、XSS、CSRF）的防护。
7. 审查测试：评估 controllers、services、guards、pipes 的测试覆盖率；验证 mock 策略是否合理，测试是否验证行为而非实现细节。
8. 验证发现（必须执行的检查点）：在最终定稿前，确认每条 Critical 和 Warning 发现都有可复现证据（文件路径、行号、精确代码片段）和具体可执行的修复方案；删除或降级那些属于风格偏好、过于主观或缺乏具体修复建议的发现。
9. 生成审查报告：输出结构化报告，包含按严重程度分类的发现（Critical、Warning、Suggestion）、正面观察，以及带代码示例的按优先级排序的建议。
10. 按固定格式组织审查结果：1. Summary（含 1-10 总体质量评分和关键观察）；2. Critical Issues（必须修复）；3. Warnings（应当修复）；4. Suggestions（可考虑改进）；5. Positive Observations（值得肯定的良好实践）；6. Recommendations（按优先级排序的下一步及代码示例）。
11. 遵循最佳实践进行审查：控制器保持轻薄并委托业务逻辑给 service；所有请求/响应载荷使用带 class-validator 的 DTO；使用 ParseUUIDPipe、ParseIntPipe 等做参数验证；使用继承 HttpException 的领域特定异常类；按功能模块组织代码并保持清晰边界与导出；优先构造函数注入，绝不对可注入服务使用 new；用 guard 做认证授权而非内联检查；用 interceptor 处理横切关注点（日志、缓存、转换）；为所有端点添加 OpenAPI 装饰器（@ApiTags、@ApiOperation、@ApiResponse）；为 service 写单元测试、为 controller 写集成测试。
12. 遵守约束与警告：不要强制单一 ORM（代码库可能使用 TypeORM、Prisma、Drizzle 或 MikroORM）；尊重现有项目约定，即使与 NestJS 默认不同；聚焦高置信度问题，避免风格偏好上的误报；审查微服务模式时考虑传输层特定约束；除非关键问题确有必要，不要建议架构重写。

适用边界 · 注意事项

• 不要强制单一 ORM，代码库可能使用 TypeORM、Prisma、Drizzle 或 MikroORM
• 不要因风格偏好或过于主观的问题产生误报，应聚焦高置信度问题
• 除非关键问题确有必要，不要建议架构重写