数据清洗分支内执行庞大集合操作会引发多重内耗：执行路径降级失去向量化优势、中间对象爆炸加剧内存压力、错误定位困难、业务逻辑耦合无法复用。
在数据清洗的分支体（如 if/else 块、map 的 lambda 内、或条件过滤后的链式操作中）直接编写庞大集合操作，看似“一气呵成”，实则会引发多重内耗，远超预期收益。这不是代码量问题，而是执行模型与运行时机制的深层冲突。
执行路径被强制降级，失去向量化优势
分支体内嵌套多层 df[cond1].groupby(...).apply(...) 或长链布尔索引（如 df.query("a>0 and b.isin(...) and c.str.contains(...).fillna(False)")），会让 pandas 无法复用底层 C/Fortran 优化路径。解释器被迫退回到 Python 层逐行执行，尤其是含 lambda、自定义函数或嵌套 isin 的场景，CPU 时间大量消耗在对象构造、类型检查和函数调用开销上，而非真实计算。
中间对象爆炸，内存压力陡增
- 一次
df.loc[condition].copy().assign(...).dropna().reset_index()可能隐式生成 3–5 个完整副本，尤其在分支中反复触发时，GC 频率飙升 - 未设
inplace=True的drop_duplicates、fillna等操作，在分支逻辑里重复调用，等于对同一份数据做多次深拷贝 - 分支判断后才执行的
pd.concat([large_df1, large_df2], axis=0)，可能让本可流式处理的数据被迫全量加载进内存
错误定位与逻辑验证彻底失效
一个写在 if is_prod: 块里的 15 行链式操作，一旦报 KeyError: 'user_id' 或 TypeError: cannot compare dtypes，你无法快速确认：是原始字段名拼写错误？是某次 rename 漏掉了？还是 groupby 后 agg 的列引用越界？每步缺乏显式 shape/dtypes 输出，调试只能靠加 print 或重启整个流程。
业务规则被锁死，无法单独测试或复用
把手机号标准化、订单状态映射、金额精度校验全揉进一个分支内的巨长 assign 链，会导致：
- 无法对“手机号清洗”逻辑单独写单元测试
- 业务方要求“只改地址解析规则”时，你得通读整段链，生怕动错一处引发连锁异常
- 后续要迁移到 Spark 或 Flink，这段强 pandas 依赖的代码几乎无法复用
不复杂但容易忽略：分支体是逻辑隔离区，不是性能优化区。该收口的并发、该拆分的清洗步骤、该提前物化的中间结果，都应在分支之外完成；分支内只保留轻量、确定、可验证的语义动作。
