代码审查清单
本文记录了一份通用的代码审查清单，可结合实际项目调整。
代码审查是保障代码质量的重要环节，以下是一份通用的代码审查清单，涵盖功能、可读性、安全性、性能、可维护性等多个维度，可根据具体项目场景（如前端、后端、移动端等）灵活调整：
一、功能正确性
- 代码是否完全实现了需求文档中的功能点？是否覆盖了所有场景（包括正常流程、边界条件、异常情况）？
- 逻辑是否严谨？是否存在逻辑漏洞（如条件判断遗漏、循环边界错误等）？
- 单元测试/集成测试是否覆盖关键逻辑？测试用例是否合理（包括正向、反向、边界值测试）？
- 与其他模块/系统的交互是否正确？接口调用参数、返回值处理是否符合约定？
二、代码可读性
- 命名是否规范？变量、函数、类、常量的命名是否清晰易懂，能否准确反映其含义（避免拼音、缩写不明确的命名）？
- 注释是否完整且必要？
- 复杂逻辑、算法是否有注释说明设计思路？
- 函数/类是否有文档注释（如参数含义、返回值、异常说明）？
- 是否存在冗余注释（如注释与代码完全重复）或过时注释？
- 代码格式是否统一？缩进、换行、空格等是否符合团队编码规范（可通过格式化工具保障）？
- 代码结构是否清晰？是否避免了过度嵌套（如多层
if-else、循环嵌套）？是否通过拆分函数/类降低复杂度？
三、安全性
- 输入验证是否完善？是否存在注入风险（如SQL注入、XSS、命令注入）？
- 敏感数据（如密码、token）是否加密存储/传输？是否避免在日志中明文打印敏感信息？
- 权限控制是否严谨？是否校验了用户/角色的操作权限？
- 依赖是否安全？是否使用了存在已知漏洞的第三方库（可通过工具扫描确认）？
- 异常处理是否合理？是否避免将详细错误信息直接暴露给用户（如堆栈信息）？
四、性能与效率
- 是否存在明显的性能瓶颈？
- 数据库查询是否优化（如是否避免全表扫描、是否合理使用索引）？
- 循环/递归是否存在不必要的重复计算？
- 大数据量处理是否考虑分批、异步等方式？
- 资源使用是否合理？
- 是否及时释放资源（如文件句柄、数据库连接、内存）？
- 是否存在内存泄漏风险（如未销毁的定时器、全局变量无节制增长）？
- 网络请求是否优化？是否避免不必要的请求（如重复请求、冗余数据传输）？
五、可维护性
- 代码是否符合DRY原则（Don’t Repeat Yourself）？是否存在重复代码（可通过抽取公共函数/工具类优化）？
- 耦合度是否过低？模块/类之间是否存在过度依赖（如直接修改其他类的私有属性）？
- 扩展性是否良好？是否便于后续功能迭代（如通过配置、抽象接口替代硬编码）？
- 是否遵循团队编码规范/设计模式？是否与项目现有代码风格保持一致？
六、错误处理与健壮性
- 异常处理是否全面？是否捕获了可能的异常（如网络错误、数据格式错误）并进行合理处理（如重试、降级、友好提示）？
- 是否存在空指针/未定义引用风险？对
null/undefined的处理是否严谨？ - 边界条件是否考虑？如数组越界、数值溢出、字符串长度限制等。
- 日志打印是否合理？是否包含关键操作日志（便于问题排查），且日志级别（info/warn/error）使用得当？
七、其他细节
- 是否删除了调试代码（如
console.log、断点、测试用临时变量）？ - 配置是否合理？是否区分了开发/测试/生产环境的配置？
- 代码是否兼容目标运行环境（如浏览器版本、Node.js版本、操作系统）？
审查建议
- 结合自动化工具（如ESLint、SonarQube、PMD等）辅助检查格式、潜在bug，聚焦人工审查逻辑和设计层面。
- 审查时以“帮助开发者提升”为目标，避免过度纠结细节（如命名风格争议），优先关注功能和安全性问题。