新手友好型 Code Review 清单
这份易上手的 Code Review 清单会帮你系统化地发现问题，同时保持友好和建设性的态度 🌟
1. 功能正确性
- 代码是否实现了需求描述的功能？
- 是否有逻辑漏洞或边界条件未处理？（如空值、越界、并发等）
- 是否有明显的 bug 或异常处理缺失？（如 try-catch、null 检查）
2. 代码可读性
- 变量、函数、类名是否清晰、有意义？（避免
a,temp,doSomething） - 注释是否必要且准确？（避免“废话注释”）
- 代码结构是否合理？是否太长、太复杂？建议拆分函数/模块。
3. 风格一致性
- 是否符合项目已有的代码风格？（缩进、命名、换行等）
- 是否使用了项目约定的 Linter / Formatter？（如 ESLint、Prettier、Black）
4. 安全性
- 是否有敏感信息泄露？（如硬编码密钥、Token、数据库密码）
- 是否存在注入风险？（SQL 注入、XSS、命令注入）
- 是否对用户输入做了有效校验？
5. 性能与资源
- 是否有低效操作？（如循环中查询数据库、重复计算）
- 是否有内存泄漏或资源未释放？（如文件句柄、数据库连接）
6. 测试覆盖
- 是否有新增或修改的单元测试？
- 测试是否覆盖了核心逻辑和边界情况？
- 是否有测试用例命名清晰、可维护？
7. 可维护性 & 扩展性
- 是否违反了单一职责原则？
- 是否引入了不必要的依赖？
- 如果未来需求变更，这段代码是否容易修改？
8. 文档与关联
- 是否更新了相关文档？（README、API 文档、注释）
- 是否关联了对应的 Issue 或任务？（在 PR 描述中写上
Closes #123）
9. PR 描述质量
- PR 标题是否清晰？（如：
fix: 修复登录页密码明文传输问题） - 描述是否说明了：为什么改、怎么改、影响范围？
- 是否有截图、日志、测试结果等辅助信息？（前端/UI 变更尤其重要）
10. 态度与沟通
- 你的评论是建设性的吗？（避免：“这代码太烂了” → 改为：“这里可以考虑用 Map 替代循环查找，性能更好”）
- 是否使用了“我们”而不是“你”？（增强协作感）
- 是否对优秀代码给予了肯定？（鼓励比批评更重要！）