代码审查清单

本文记录了一份通用的代码审查清单，可结合实际项目调整。

---

代码审查是保障代码质量的重要环节，以下是一份通用的代码审查清单，涵盖功能、可读性、安全性、性能、可维护性等多个维度，可根据具体项目场景（如前端、后端、移动端等）灵活调整：

一、功能正确性

1. 代码是否完全实现了需求文档中的功能点？是否覆盖了所有场景（包括正常流程、边界条件、异常情况）？
2. 逻辑是否严谨？是否存在逻辑漏洞（如条件判断遗漏、循环边界错误等）？
3. 单元测试/集成测试是否覆盖关键逻辑？测试用例是否合理（包括正向、反向、边界值测试）？
4. 与其他模块/系统的交互是否正确？接口调用参数、返回值处理是否符合约定？

二、代码可读性

1. 命名是否规范？变量、函数、类、常量的命名是否清晰易懂，能否准确反映其含义（避免拼音、缩写不明确的命名）？
2. 注释是否完整且必要？
   • 复杂逻辑、算法是否有注释说明设计思路？
   • 函数/类是否有文档注释（如参数含义、返回值、异常说明）？
   • 是否存在冗余注释（如注释与代码完全重复）或过时注释？
3. 代码格式是否统一？缩进、换行、空格等是否符合团队编码规范（可通过格式化工具保障）？
4. 代码结构是否清晰？是否避免了过度嵌套（如多层if-else、循环嵌套）？是否通过拆分函数/类降低复杂度？

三、安全性

1. 输入验证是否完善？是否存在注入风险（如SQL注入、XSS、命令注入）？
2. 敏感数据（如密码、token）是否加密存储/传输？是否避免在日志中明文打印敏感信息？
3. 权限控制是否严谨？是否校验了用户/角色的操作权限？
4. 依赖是否安全？是否使用了存在已知漏洞的第三方库（可通过工具扫描确认）？
5. 异常处理是否合理？是否避免将详细错误信息直接暴露给用户（如堆栈信息）？

四、性能与效率

1. 是否存在明显的性能瓶颈？
   • 数据库查询是否优化（如是否避免全表扫描、是否合理使用索引）？
   • 循环/递归是否存在不必要的重复计算？
   • 大数据量处理是否考虑分批、异步等方式？
2. 资源使用是否合理？
   • 是否及时释放资源（如文件句柄、数据库连接、内存）？
   • 是否存在内存泄漏风险（如未销毁的定时器、全局变量无节制增长）？
3. 网络请求是否优化？是否避免不必要的请求（如重复请求、冗余数据传输）？

五、可维护性

1. 代码是否符合DRY原则（Don't Repeat Yourself）？是否存在重复代码（可通过抽取公共函数/工具类优化）？
2. 耦合度是否过低？模块/类之间是否存在过度依赖（如直接修改其他类的私有属性）？
3. 扩展性是否良好？是否便于后续功能迭代（如通过配置、抽象接口替代硬编码）？
4. 是否遵循团队编码规范/设计模式？是否与项目现有代码风格保持一致？

六、错误处理与健壮性

1. 异常处理是否全面？是否捕获了可能的异常（如网络错误、数据格式错误）并进行合理处理（如重试、降级、友好提示）？
2. 是否存在空指针/未定义引用风险？对null/undefined的处理是否严谨？
3. 边界条件是否考虑？如数组越界、数值溢出、字符串长度限制等。
4. 日志打印是否合理？是否包含关键操作日志（便于问题排查），且日志级别（info/warn/error）使用得当？

七、其他细节

1. 是否删除了调试代码（如console.log、断点、测试用临时变量）？
2. 配置是否合理？是否区分了开发/测试/生产环境的配置？
3. 代码是否兼容目标运行环境（如浏览器版本、Node.js版本、操作系统）？

审查建议

• 结合自动化工具（如ESLint、SonarQube、PMD等）辅助检查格式、潜在bug，聚焦人工审查逻辑和设计层面。
• 审查时以“帮助开发者提升”为目标，避免过度纠结细节（如命名风格争议），优先关注功能和安全性问题。