Python代码审查这事儿，说起来简单，做起来经常走偏。很多团队把“代码审查”搞成了“大家一起逐行读代码”，效率低不说，还容易漏掉真正致命的问题。其实核心思路很简单——用自动化工具兜底常规问题，然后让人把精力放在真正需要判断的地方。
静态分析工具：先扫一遍雷
工具能干的，就别让人干。语法错误、未使用的变量、函数复杂度过高、潜在的类型隐患……这些重复性的检查工作，交给工具几秒钟就能搞定。
- pylint：覆盖面最广，从编码规范（PEP 8）到逻辑错误、接口一致性都能管，还能自定义规则、生成评分报告，适合做全面的质量体检。
- flake8：轻量组合拳（pyflakes + pycodestyle + mccabe），速度飞快，CI里过一遍基础规范和常见bug首选。
- bandit：专门盯着安全漏洞——硬编码密码、危险的eval()、不安全的反序列化调用，这些它都能揪出来。
- mypy：配合类型提示做静态类型检查，参数类型写错了、返回值类型对不上，提交之前就能发现。
把检查嵌入流程，而不是事后补票
审查的效果，很大程度上取决于时机。写完代码立刻检查，和等到合并前突击检查，修复成本差的不是一星半点。
- IDE里配置好保存时自动运行flake8或pylint，问题实时标红，写代码的时候就能顺手改掉。
- Git提交前加pre-commit钩子，用pre-commit框架统一管理pylint、black、isort这些工具，不达标直接禁止提交。
- CI流水线（比如GitHub Actions、GitLab CI）里强制跑mypy、bandit和测试覆盖率，有任一失败就阻断合并。
人工审查：看机器看不到的东西
工具再强，也只是辅助。业务逻辑是否合理、接口是否易用、异常处理是否到位、测试是否覆盖了边界场景——这些才是人工审查该花时间的地方。
- 新增或修改的函数，重点看输入校验是否充分，错误路径有没有返回明确信息，有没有隐藏的副作用。
- 测试用例检查：正常流、异常流、边界值（空列表、None、超大数）都覆盖到了吗？mock是不是真实反映了依赖行为？
- 可维护性：函数职责单一吗？命名能不能自解释？注释写的是“为什么”而不是“做什么”？
定几条质量红线，避免无休止的争论
没有统一标准，审查很容易变成主观口水战。建议白纸黑字写进CONTRIBUTING.md，哪些是不可妥协的底线。
- 所有新模块必须有类型提示（至少函数签名要写清楚）。
- 关键路径代码（支付、权限、数据导出这些）必须有对应的单元测试，覆盖率不低于80%。
- 禁止使用exec、eval、os.system这类高风险调用，除非有强理由且经过安全评审。
- 每个PR的描述必须包含修改动机、影响范围和手动验证步骤——哪怕只有一句话也行。
