核心问题是逻辑分散、职责不清、变更困难；优化方向包括：用卫语句提前拦截校验，按执行概率重排条件顺序，用表驱动替代硬编码分支，以及用多态或策略模式应对本质不同的行为。
Java 中 if-else 分支过多，核心问题不是“用了 if-else”，而是逻辑分散、职责不清、变更困难。优化方向很明确：让高频路径更短、异常路径更早暴露、相同结构的判断更集中、未来新增分支不改老代码。
用卫语句提前拦截，释放主干逻辑
把空值检查、参数非法、权限不足、状态不合法等低成本、高确定性的校验放在最前面，单独成行并立即返回或抛异常。主业务流程就自然浮到顶层缩进，不再被层层包裹。
- 每个卫语句只做一件事，比如
if (order == null) throw ...或if (!user.isActive()) return; - 避免在卫语句里写业务计算，它只负责“守门”，不参与“干活”
- 顺序上，先判 null，再判空字符串，再判数值范围，最后才是业务状态流转
按执行概率重排 if-else if 顺序
真实流量中，80% 的请求往往落在少数几个典型分支上。把高频、轻量、确定性强的条件往前放，能显著降低平均判断次数。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 例如订单状态判断：先
status == PAID（内存比对，65% 占比），再status == SHIPPED（20%），最后才调用需查库的isRefundPending() - 避免把耗时方法（如远程调用、数据库查询）放在靠前位置，否则每次都要执行
- 守卫条件也属于“高频轻量”，应优先于业务分支出现
用表驱动替代硬编码分支
当 if-else 是根据某个离散值（如类型码、状态码、字符串标识）选择行为时，Map 或枚举比一长串 if-else 更清晰、更易扩展。
- 简单映射：用
Map.of("VIP", "15%", "GOLD", "10%")替代 if-else 判字符串 - 复杂逻辑：Map 的 value 改为
Function<t r></t>或策略对象，实现“配置即逻辑” - 状态描述类场景：定义枚举，每个实例自带描述、转换方法，避免重复 if 判 int 值
用多态或策略模式应对本质不同的行为
如果每个分支执行的是完全不同的算法、规则或数据处理方式，说明它们本该是不同类型的职责。这时 if-else 就是设计坏味道的信号。
- 提取公共接口（如
OrderHandler），每个状态对应一个实现类（PaidHandler、ShippedHandler） - 配合工厂或 Spring Bean 名称查找，运行时动态获取处理器，新增状态只需加类、注册 bean，不碰原有 if-else
- 适合分支数超过 5–6 个，且各分支逻辑复杂度差异大、后续可能独立演进的场景
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
