Code review cn

Code Review 规范

Review 评论分级

每条 review 评论必须标注严重级别，避免"我觉得可以改一下"这种模糊反馈：

前缀	含义	是否阻塞合并
🔴 必须修改:	有 bug、安全漏洞、数据丢失风险	是
🟡 建议修改:	可维护性问题、性能隐患、不符合规范	否，但强烈建议
🟢 可选优化:	代码风格、命名建议、更优雅的写法	否
💬 讨论:	不确定的问题，想听作者的想法	否
👍 赞:	写得好的地方，值得学习	—

示例

🔴 必须修改: 这里直接拼接 SQL 会导致注入漏洞，请用参数化查询。

🟡 建议修改: 这个循环里每次都查数据库，N+1 问题。
建议用 IN 查询一次取出，或者用 DataLoader 批量加载。

🟢 可选优化: `getUserInfo` 改成 `fetchUserProfile` 更准确，
因为这个函数是异步请求而不是同步获取。

💬 讨论: 这里用乐观锁还是悲观锁？我觉得并发量不大的话乐观锁够了，
但你更了解业务场景，想听听你的想法。

👍 赞: 这个错误重试的退避策略写得很好，指数退避 + 抖动，很专业。

Review 检查清单

按优先级从高到低检查：

1. 安全性（最高优先级）

• SQL 注入：是否使用参数化查询
• XSS：用户输入是否转义后再渲染
• 认证：接口是否正确校验了登录状态
• 授权：是否检查了当前用户有权操作该资源
• 敏感数据：密码是否加密存储、日志是否脱敏、响应是否泄露内部信息
• 文件上传：是否限制了类型和大小

2. 正确性

• 边界条件：空数组、null、0、空字符串、超长输入
• 并发安全：共享状态是否有竞态条件
• 错误处理：异常是否被正确捕获和处理（不是 catch 后吞掉）
• 事务：涉及多表操作是否在事务中
• 幂等性：重复请求是否会产生副作用

3. 可维护性

• 命名：变量名和函数名是否准确表达意图
• 复杂度：单个函数是否超过 50 行、嵌套是否超过 3 层
• 重复代码：是否有可以抽取的公共逻辑
• 魔法数字：是否有未解释的硬编码值
• 类型安全：是否有 any 类型、是否缺少类型定义

4. 性能（仅在有性能要求时检查）

• N+1 查询：循环中是否有数据库查询
• 大数据量：列表是否有分页、是否有内存溢出风险
• 缓存：频繁读取的数据是否考虑缓存
• 索引：新增的查询条件是否有对应索引

PR 描述模板

## 做了什么
简要描述这个 PR 的改动内容。

## 为什么
说明背景和动机。关联的 issue 或需求链接。

## 怎么测试
1. 步骤一
2. 步骤二
3. 预期结果

## 影响范围
- [ ] 数据库变更（需要跑迁移）
- [ ] API 接口变更（需要通知前端）
- [ ] 配置变更（需要更新环境变量）
- [ ] 破坏性变更（需要通知相关方）

## 截图/录屏
（如果是 UI 变更，贴截图）

什么时候该 Approve

所有 🔴 必须修改 都已解决？
├── 否 → Request Changes
└── 是 → 有 🟡 建议修改 未解决？
    ├── 是 → 和作者讨论，如果作者有合理理由可以 Approve
    └── 否 → Approve ✅

Review 评论的写法

不要这样写

这里有问题。
这样写不好。
改一下。

要这样写

🔴 必须修改: `password` 字段在响应中被返回了，会泄露用户密码。
建议在 serializer 中排除 password 字段，或者用 select 只查需要的字段。

参考：
const user = await prisma.user.findUnique({
  where: { id },
  select: { id: true, name: true, email: true }, // 不查 password
})

原则

• 说清楚问题是什么（不只是"有问题"）
• 说清楚为什么是问题（安全？性能？可维护性？）
• 给出具体的修改建议（不只是"改一下"）
• 如果有参考代码，直接贴出来