分支体不是功能封装单元，将大量逻辑塞入if/else或switch会破坏单一职责、阻碍复用与测试、放大维护成本、削弱可扩展性。
因为分支体本身是逻辑分隔点，不是功能封装单元。当大量业务逻辑直接塞进 if、else if 或 switch 的花括号内，就等于把本该由独立函数承担的职责，强行压在一个判断路径里。
破坏单一职责，让方法失去焦点
一个方法理应只做一件事，比如“处理订单支付”。但如果在 if (paymentMethod == "alipay") { ... 80 行支付宝专用逻辑 ... } 里堆砌签名验签、异步回调处理、失败重试、对账标记等全部细节，这个方法实际承担了支付网关调用、状态机管理、日志记录、异常恢复等多个职责——它已不再是“处理支付”，而是“替所有支付方式打工”。
阻碍复用与测试
庞大分支体中的代码通常紧耦合于当前条件上下文，难以单独提取或替换。例如，微信支付分支里的验签逻辑和支付宝分支里的几乎一样，但因混在各自大段代码中，无法被识别为可提取的公共能力。结果就是：改一处验签规则，得手动同步修改三四个分支；写单元测试时，必须构造完整条件链才能覆盖某条路径，测试用例臃肿且脆弱。
放大阅读与维护成本
- 每次打开这个方法，第一反应不是看主流程，而是“先找我关心的那个分支在哪”——相当于在源码里做文本搜索
- 新增一种支付方式？不是加个
else if就完事，而是要在已有千行方法里插入新逻辑，极易引发缩进错乱、遗漏break、误删return等低级错误 - Code Review 时， reviewer 很难确认新分支是否重复实现了已有工具函数（比如又写了一遍时间戳校验），因为相关代码被淹没在 200 行嵌套中
削弱可扩展性与演进弹性
当支付渠道从 3 个扩到 10 个，方法体可能膨胀至 1500 行。此时再想引入策略模式、支持运行时动态加载渠道插件，或对接新风控系统统一拦截，都会因结构僵化而举步维艰。分支体越大，抽象出接口或策略类的阻力就越强——重构意愿直接被“不敢动”的心理门槛压垮。
