函数拆分应遵循单一职责原则，按业务逻辑边界、重复表达式、参数分支和强关联状态四类场景进行：如将“清洗数据”“计算指标”等提取为独立函数；封装校验、格式化等通用逻辑；避免flag参数切换流程，改用明确命名函数；高耦合场景可引入类组织。
函数过长通常意味着职责不单一、可读性差、难以测试和复用。拆分的核心原则是：每个函数只做一件事，且这件事要清晰可命名。
按业务逻辑边界拆分
观察函数中是否存在明显的逻辑段落，比如“加载数据 → 清洗数据 → 计算指标 → 生成报告”。这些就是天然的拆分点。
- 把“清洗数据”提取为 clean_user_data(data)，输入原始数据，输出清洗后结果
- 把“计算指标”单独写成 calculate_user_metrics(cleaned_data)，专注数值逻辑，不碰文件或网络
- 原函数就变成几行调用，像流水线一样清晰
把重复或复杂表达式封装成小函数
如果某段代码出现两次（如日期格式化、JSON字段校验），或一个条件判断特别长（如多层嵌套的 if-elif-else + 正则匹配），就值得独立出来。
- 例如：is_valid_email(text) 封装邮箱校验逻辑，主函数里直接用布尔值判断
- 再如：format_timestamp(ts, tz='UTC') 替代散落在各处的 datetime.strftime(...) 调用
- 好处是命名即文档，也方便单元测试和未来替换实现
用参数控制行为，而不是堆砌分支
避免写出一个函数通过 flag 参数切换完全不同的流程（如 process(data, mode='fast') 和 process(data, mode='accurate')）。这种函数本质是多个函数的混合体。
- 拆成 process_fast(data) 和 process_accurate(data)，各自专注一种策略
- 如果共用大量前置步骤，可再抽一个 prepare_input(data) 供两者调用
- 调用方根据场景明确选择，语义更清楚，也不用担心 flag 传错导致静默错误
考虑使用类来组织强关
当一组函数频繁共享状态（如配置、缓存、连接对象），或操作围绕同一类数据展开（如处理一份 Excel 报表的多个环节），函数拆分可能不如面向对象自然。
- 例如：把报表处理逻辑封装进 ReportProcessor 类，用实例属性保存中间结果
- 每个方法对应一个步骤：.load()、.validate()、.export_pdf()
- 不是为了用类而用类，而是当函数间耦合变高、参数越来越多时，类能更好管理依赖和生命周期
