code-review

name	code-review
description	全栈代码审查规范（质量/性能/安全/架构/风格）。用于 Code Review、PR 审查、质量门禁、安全与性能检查等任务。

何时使用

• 审查功能实现逻辑
• 全栈代码质量检查
• 性能瓶颈分析
• 安全风险识别

核心职责

1. 代码正确性审查

后端审查要点

• Share层

  • 只包含通用的逻辑算法等，不涉及任何业务数据的操作
  • 封装通用的第三方库的调用，如缓存/邮件/消息队列等

• Manager 层:

  • 业务逻辑是否在 Manager 中而非 Controller？
  • 是否继承 ManagerBase<T> 或 ManagerBase？
  • 是否避免了 Manager 之间的直接调用？
  • 异常处理是否抛出 BusinessException？
  • 查询是否使用 Select 投影而非 Include 加载整个导航属性？
  • 批量操作是否使用 EFCore.BulkExtensions？
  • 事务操作是否使用 ExecuteInTransactionAsync？

• Controller 层:

  • 是否继承 RestControllerBase？
  • 是否避免直接访问 DbContext？
  • 错误处理是否使用 Problem() / NotFound()？
  • 是否避免使用 ApiResponse 包装器？

前端审查要点

• 组件设计:

  • 是否使用 Angular Material 组件库？
  • 状态管理是否优先使用 signals？
  • 订阅是否正确清理（使用 takeUntilDestroyed 或 async pipe）？

• 国际化:

  • 字符串是否使用 i18n 而非硬编码？
  • 键名是否与 app/share/i18n-keys.ts 对齐？

2. 性能审查

• 数据库查询:

  • 是否存在 N+1 查询问题？
  • 是否滥用 Include 导致过量数据加载？
  • 分页查询是否正确实现？
  • 是否缺少必要的索引？

• API 设计:

  • 列表接口是否返回分页数据而非全量数据？
  • DTO 是否只包含必要字段（避免过度传输）？
  • 是否存在冗余的 HTTP 请求？

• 前端性能:

  • 组件是否存在不必要的重绘？
  • 是否滥用 ChangeDetectorRef.detectChanges()？
  • 列表渲染是否使用 trackBy？

3. 安全审查

• 输入验证:

  • API 边界是否进行输入验证？
  • 是否使用 [Required], [MaxLength], [Range] 等注解？
  • 客户端验证是否与服务端一致？

• 权限控制:

  • Controller 是否有适当的授权检查（[Authorize]）？
  • 是否存在越权访问风险？

• 敏感信息:

  • 是否泄露敏感数据（如密码、token）？
  • 错误信息是否包含内部实现细节？

4. 架构和设计审查

• 依赖关系:

  • 模块之间是否存在依赖?(CoreMod 除外)
  • 是否存在循环依赖？
  • Manager 之间是否存在不必要的直接调用？

• 代码复用:

  • 是否有重复代码应提取为共享方法？

5. 代码风格和可维护性

• 注释和文档:

  • 复杂逻辑是否有必要的注释？
  • 类，属性，公共 API 是否有 XML 文档注释？

• 错误处理:

  • 异常是否正确捕获和处理？
  • 日志记录是否充分？

审查输出格式

问题报告模板

# 代码审查报告

**审查范围**: [文件路径或模块名称]  
**审查日期**: [日期]  
**审查结果**: ✅ 通过 / ⚠️ 需改进 / ❌ 阻断

## 🔴 阻断性问题（必须修复）

### [问题标题]
- **文件**: `path/to/file.cs#L10-L15`
- **问题描述**: 明确说明问题
- **风险等级**: Critical / High
- **建议修复**:
  ```csharp
  // 修复后的代码示例

⚠️ 改进建议

[建议标题]

• 文件: path/to/file.ts#L42
• 当前问题: 描述不够理想的实现
• 改进方案: 提供优化建议
• 收益: 说明改进后的好处（性能/可维护性等）

📚 参考资料

• Perigon Best Practices

审查原则

1. 准确性优先: 基于项目实际规范而非个人偏好
2. 问题分级: 区分阻断性问题、改进建议和良好实践
3. 提供方案: 不仅指出问题，还要给出具体修复建议
4. 引用规范: 每个问题都应引用相关 Skill 文档或官方文档
5. 保持客观: 避免主观臆断，基于事实和规范进行评审
6. 建设性反馈: 肯定好的实践，鼓励持续改进