本文目录导读：
Python项目代码审查要做到高效，核心思路是：“自动化 + 聚焦关键领域 + 标准化的流程”，不要试图靠肉眼去抓所有问题,那样既累又容易遗漏。
以下是一套经过实践检验的高效代码审查方法，分为准备阶段、审查焦点、自动化工具链、审查流程四个部分。
准备阶段：审查前的黄金30秒
在打开代码之前，先花30秒明确目标,能大幅提升效率。
- 明确审查目的：
- 是功能审查（逻辑是否正确）？
- 还是代码规范审查（风格、性能、安全）？
- 或者紧急修复审查（平衡速度与质量）？
- 获取上下文：
- 阅读PR（Pull Request）的标题和描述，如果描述不清,立刻要求提交者补充。
- 查看关联的Jira/Trello/Issue：理解业务需求,避免审查无源之水。
- 设置时间盒：
- 建议每次审查不超过400-500行代码或30-45分钟，超过这个量，大脑容易疲劳，错误率飙升，如果改动太大，要求开发者拆分PR（遵循“小步提交”原则）。
审查核心焦点：分层递进
不要同时检查所有东西,按照优先级分层审查：
第一层：逻辑与正确性（最耗脑力，优先做）
- 边界条件：列表为空、数字为0或负数、字符串为None时会发生什么？
- 状态变更：有没有未处理的异常？事务是否回滚？数据库操作是否有竟态条件？
- 副作用：函数是否修改了传入的可变对象（如列表、字典）？这在Python中很常见。
- 算法复杂度：有没有不必要的O(n²)循环？可以用
set或dict降低复杂度吗？
第二层：可读性与可维护性（影响长期成本）
- 命名：
temp,data,thing等名字是否应该更明确（如user_list,response_json）？ - 函数长度：一个函数是否太长,需要拆解成多个小函数？
- “反直觉”代码：任何需要停下来思考3秒才能看懂的地方,建议加上注释或重构。
第三层：Python专属陷阱（高频问题）
- 可变默认参数：
def func(lst=[])会导致大坑，应改为None。 except:裸异常：推荐使用except (ValueError, KeyError):。isvs ：判断None用is，比较数值/字符串用。- 深拷贝 vs 浅拷贝：
copy()还是deepcopy()？尤其是在类中。 - 迭代器耗尽：
map()/filter()/生成器 只能遍历一次,第二次就是空。
第四层：性能与安全（视项目而定）
- SQL注入：确保使用参数化查询（
WHERE name = ?）而非拼接字符串。 - 循环内IO操作：是否可以把数据库查询移出for循环（使用
IN查询批量获取）？ - 内存占用：是否一次性加载了过大的CSV到内存？可以用迭代器逐行读取吗？
自动化工具链：让机器人干90%的脏活
审查前让工具先跑一遍,你只关注逻辑和设计。
| 工具 | 用途 | 推荐理由 |
|---|---|---|
| Black | 代码格式化 | 终结风格争论（缩进、空格、引号），强制统一。 |
| Flake8 / Ruff | 静态检查 | 发现未使用变量、过长代码、拼写错误。Ruff速度极快。 |
| Pylint | 深度代码分析 | 检查代码坏味道、命名规范、复杂度。 |
| Mypy / Pyright | 类型检查 | 对于大型项目非常重要，能发现很多隐晦的类型不匹配。 |
| Bandit | 安全扫描 | 自动发现常见安全问题（如eval()使用、硬编码密码）。 |
| Vulture | 死代码检测 | 找出从未被调用的函数或未使用的导入。 |
| Pre-commit | 本地Git钩子 | 在git commit前自动运行上述工具，堵住源头。 |
配置示例（.pre-commit-config.yaml）：
repos:
- repo: https://github.com/psf/black
rev: 24.8.0
hooks:
- id: black
- repo: https://github.com/PyCQA/flake8
rev: 7.1.0
hooks:
- id: flake8
- repo: https://github.com/pre-commit/mirrors-mypy
rev: v1.11.2
hooks:
- id: mypy
审查流程与沟通技巧
工具和检查项是骨架,沟通和流程是灵魂。
-
逐迭代审查，而非逐行：
- 先看改动摘要（Diff overview），理解整体属于新增、修改还是重构。
- 先看测试文件（如果有）,好的测试是代码说明书。
- 再看核心逻辑，最后看配置/文档/注释。
-
注释要有建设性：
- 坏示例：“这里写得不对。”
- 好示例：“
get_user_data的顺序可能影响缓存命中率，建议将访问频率高的ID放前面，或者用OrderedDict，你觉得呢？” - 用问句代替命令：“这段逻辑可以复用
send_email函数吗？加个参数控制即可。” 比“把这段改成复用send_email”更好。
-
建立“代码审查检查清单”（项目团队共识）：
所有新API端点是否有权限校验？所有SQL是否参数化？日志是否不打印敏感信息？
-
处理“急活儿”：
- 如果线上问题是紧急Bash，可以先合并，后补审查（Post-commit review）。
- 但必须记录在案,并要求开发在24小时内补充审计日志和回顾。
常见误区（避坑指南）
- 不要做“吹毛求疵”的审查：
- 如果格式问题已有Black/Flake8兜底，不要在Code Review里讨论“这里没加空格”、“那里用了单引号”。
- 专注于“让代码更安全、更清晰、更健壮”,风格问题交给Linter。
- 不要大包大揽：
- 如果一次PR修改了超过1000行代码，不要强行看完,要求提交者拆分。
- 或者，只看自己负责或最关键的模块,其他部分请团队其他成员交叉审查。
- 不要延宕：
- 设定SLA（服务水平协议）：关键修改4小时内回复,一般修改24小时内回复。
- 如果发现大问题，尽快指出，拖太久会让改动者忘记上下文,并产生挫败感。
高效审查的“三字箴言”
- 自动：让Linter、Type Checker、Security Scanner做80%的重复工作。
- 聚焦：只审查逻辑、安全、可维护性；不做人类Linter。
- 迭代：小PR、快速反馈、有温度的沟通。
