Python代码审查核心是保障可读性、健壮性与可维护性；重点审查命名规范（如is_authenticated）、异常处理（捕获具体类型并记录日志）、函数单一职责（≤25行、≤4参数）、依赖显式管理（版本锁定）及安全配置（避免shell注入）。
Python 代码审查不是挑错比赛，而是帮团队守住可读性、健壮性和长期可维护性的关键环节。重点不在“写得对不对”，而在“别人能不能快速看懂、安全地改、不踩坑地扩”。
变量与命名是否清晰传达意图
命名是代码的第一文档。审查时盯住那些让人犹豫三秒的变量名：比如 tmp、data、res、x1、val——它们几乎从不说清“是什么”或“为什么存在”。函数名也一样，process()、handle() 这类动词太泛，应明确动作对象和边界，如 parse_user_config_from_yaml() 或 drop_expired_cache_entries()。
- 检查是否所有常量都用大写加下划线（MAX_RETRY_ATTEMPTS），且定义位置合理（避免散落在函数内部）
- 确认布尔变量以 is_、has_、can_ 开头（如 is_authenticated），不出现 flag、status 等模糊词
- 警惕缩写——除非是广泛共识（如 id、url、cfg），否则全拼更安全（user_profile 比 usr_prf 好）
异常处理是否真实覆盖风险点
Python 的 try...except 容易写成“防崩溃装饰”，但真正要防的是业务逻辑断裂。常见问题包括：只捕获 Exception 却不做区分、吞掉异常不记录、在不该恢复的地方强行 pass。
- 优先捕获具体异常类型（FileNotFoundError、requests.Timeout），避免掩盖意料之外的错误
- 所有 except 块至少要记录日志（logger.exception()），禁止空 except:
- 检查 finally 或上下文管理器（with）是否用于资源清理，而不是依赖 except 做收尾
函数是否单一职责且边界清晰
一个函数如果超过 25 行、参数多于 4 个、或名字里带 “and”/“or”，大概率该拆了。长函数难测试、难复用、难定位问题；参数过多说明职责过杂或缺少封装。
立即学习“Python免费学习笔记（深入）”；
- 检查是否有重复逻辑块——相同数据处理、相似条件分支，应抽为独立函数或工具方法
- 确认函数返回值类型稳定：不一会儿返回 dict，一会儿返回 None 或 str，会迫使调用方不断做类型判断
- 留意副作用：修改传入的可变对象（如 list、dict）、全局状态、文件系统等，应在函数名或文档中明确体现（如 sort_inplace()、save_to_disk()）
依赖与环境是否显式、可控
Python 项目跑不起来，十次有八次栽在依赖上。审查时不能只看代码，要同步检查 requirements.txt 或 pyproject.toml 是否锁定版本、是否有未声明的隐式依赖（比如靠系统 PATH 找到的命令行工具）。
- 确认第三方库版本使用 == 锁定（开发/测试环境），或至少用 >= + 组合限制范围（生产环境）
- 检查是否误用 os.system() 或 subprocess.run(..., shell=True)，尤其当参数来自用户输入——这是典型注入漏洞温床
- 验证配置加载方式：硬编码路径、环境变量缺失默认值、敏感信息明文写在代码里，都属于高危信号
