静态分析三步法：先用flake8检查PEP 8风格和硬性错误，再用pylint深入分析逻辑与结构；接着用mypy做类型检查捕获运行时错误；最后用radon和vulture识别高复杂度与无用代码以指导安全重构。
用pylint和flake8做基础静态检查
静态分析是提升Python代码质量的第一步，不用运行就能发现潜在问题。pylint能检查命名规范、未使用变量、重复代码、复杂度超标等；flake8更轻量，专注PEP 8风格和常见错误（比如未定义变量、多余的空格）。建议两者配合使用：先用flake8快速过一遍格式和硬性错误，再用pylint深入扫描逻辑和结构问题。
安装后可直接在项目根目录执行：
flake8 --max-line-length=88 --extend-ignore=E203,W503 src/
pylint --rcfile=.pylintrc --output-format=colorized src/
关键点：通过.flake8和.pylintrc配置文件统一团队标准，避免每次手动加参数；把--max-line-length=88设为默认（兼容black），禁用E203和W503避免与自动格式化工具冲突。
用mypy做类型检查，提前捕获运行时错误
Python是动态类型语言，但加上类型提示（type hints）后，mypy就能在编码阶段发现参数错传、返回值误用、None解引用等问题。这不是要你写满所有函数的类型注解，而是从高频出错模块（如数据处理、API响应解析）开始逐步覆盖。
立即学习“Python免费学习笔记（深入）”；
例如一个易错的字典取值函数：
def get_user_name(data: dict) -> str:
return data["name"] # 如果data没有name键，运行时报KeyError
加上类型和安全检查后：
from typing import Optional, Dict
<p>def get_user_name(data: Dict[str, object]) -> Optional[str]:
return data.get("name") # 返回Optional[str]，调用方必须处理None情况</p>建议策略：
- 在pyproject.toml中配置mypy，开启disallow_untyped_defs = true强制函数有类型注解
- 对第三方库缺失类型提示的情况，用types-xxx包补充（如types-requests）
- CI流程中加入mypy src/ --show-error-codes，失败即阻断合并
用radon和vulture识别可重构点
静态分析不只是找bug，更要帮你看清代码“哪里该改”。radon分析圈复杂度（CC）、行数（LOC）、参数个数，帮你定位高风险函数；vulture则专门找出未使用的变量、函数、导入项——这些往往是重构前的“清理入口”。
例如执行：
radon cc -s -a src/ | head -20 # 查看最复杂的前20个函数 vulture src/ --min-confidence 80 # 找出高置信度的无用代码
典型重构场景：
- 某个函数CC > 10 → 拆分为多个职责单一的小函数
- 类里有大量if-elif-else判断同一字段 → 考虑策略模式或映射表驱动
- vulture报告某函数从未被调用 → 确认是否已废弃，果断删除
- 多个模块重复相似逻辑 → 提炼为工具函数或基类方法
重构不是重写，要靠测试兜底
没有测试的重构等于埋雷。哪怕只有几条关键路径的单元测试，也能让你改得放心。重点不是覆盖率数字，而是覆盖输入边界、异常分支和核心状态流转。
操作建议：
- 重构前，先为待修改模块补1–3个最典型的测试用例（用pytest + unittest.mock）
- 用pytest --tb=short -x快速验证修改前后行为一致
- 对涉及I/O或外部依赖的函数，优先mock掉，聚焦逻辑本身
- 如果原项目没测试，从CLI入口或API视图层开始写端到端测试，它们最容易描述“做了什么”
记住：每次只做一个小改动（比如提取一个函数、简化一个条件表达式），跑通测试再继续。这样既可控，也方便回滚。
