函数应只做一件事，按输入/输出边界、异常分支、复用意图、测试友好性四类场景拆分，确保职责单一、命名清晰、无副作用、易测易维护。
一个函数只做一件事，是让代码更易读、可测、可维护的核心原则。拆分函数不是为了多写几行，而是把混在一起的逻辑理清楚，让每一步都“名副其实”。
按输入/输出边界拆分
当一个函数既要处理原始数据、又要格式化、还要写入文件，就该切开。比如读取 CSV、清洗字段、生成报告三步，硬塞在一个函数里，改清洗规则就得动整个流程。
- 提取数据 → 单独函数，返回标准结构（如 list[dict]）
- 转换数据 → 接收上一步结果，专注字段映射、类型转换、空值处理
- 输出结果 → 只管把数据写成 CSV/JSON/打印，不碰业务逻辑
按异常场景或分支路径拆分
if-elif-else 嵌套深、各分支处理逻辑差异大时，分支本身就可以变成函数。例如用户登录验证：检查账号是否存在、密码是否正确、是否被锁定、是否过期——每个判断条件背后都有一套校验逻辑。
- check_user_exists(username) —— 查库，返回 bool 或 User 对象
- verify_password(user, raw_pw) —— 只比对密码，不处理 session 或日志
- is_account_active(user) —— 专注状态字段和时间判断
按复用意图拆分
如果某段逻辑在两个以上地方出现，哪怕只有 3 行，也值得拎出来。比如统一的时间戳转本地时区、HTTP 请求头组装、JSON 序列化前的 datetime 处理。
立即学习“Python免费学习笔记（深入）”；
- 命名体现用途，如 to_local_time(dt, tz='Asia/Shanghai')
- 不带副作用（不修改入参、不读写全局变量、不发请求）
- 加类型提示和简短 docstring，说明它“是什么”，而不是“怎么用”
按测试友好性反向驱动拆分
写单元测试时发现某个函数不好 mock、不好断言、覆盖路径太多，往往是职责过重的信号。能独立测试的函数，通常就是单一职责的。
- 一个函数对应一个 assert 主干（例如只验证返回值结构，或只验证是否抛出特定异常）
- 外部依赖（数据库、网络、文件）尽量抽成参数或通过接口注入
- 避免在函数内部调用 print()、logging.info() 等干扰断言的行为
拆分不是越细越好，关键看是否让每段代码的“目的”一目了然。函数名能说清它做什么，调用时不用翻进去看，就差不多到位了。
