应将长条件表达式抽取为语义清晰的布尔变量或私有方法，如isAdultAndActive或canApplyPromotion()，避免if中嵌套复杂逻辑；注意短路失效、否定逻辑可读性差及调试可观测性问题。
把长条件表达式抽成布尔变量
Java 中 if 里堆砌多个 &&、|| 和括号嵌套，第一眼根本看不出在判断什么。这不是风格问题，是维护时的事故高发区——改一个条件可能连带影响整个逻辑链，还容易漏掉括号配对。
直接把整段条件拎出来，赋给一个语义清晰的 boolean 变量，比如 isEligibleForDiscount 或 shouldSkipValidation。名字本身就得说明“它为什么重要”，而不是描述“它怎么算出来的”。
- 别用
flag1、condition这类无意义名 - 计算逻辑如果超过 3 行，就该单独提成私有方法，别塞在变量初始化里
- 注意短路求值失效风险：赋值后变量是静态快照，而原条件中
obj != null && obj.isActive()在抽成变量后，如果obj后续被修改，变量值不会自动更新
if (user != null && user.getAge() >= 18 && !user.isBlocked() && user.hasValidEmail()) { ... }
→ 改成：
boolean isAdultAndActive = user != null && user.getAge() >= 18 && !user.isBlocked() && user.hasValidEmail();<br>if (isAdultAndActive) { ... }
用私有方法封装业务含义明确的判断逻辑
当某个条件反复出现在多个 if 中，或者它本身涉及状态校验、边界处理、外部依赖（比如调用 service.isValid()），硬塞进 if 就等于把业务规则藏进控制流里，谁都不敢动。
立即学习“Java免费学习笔记（深入）”；
拆成 private boolean 方法，名字就是一句完整业务断言，比如 canApplyPromotion()、isWithinRetryLimit()。方法体内可以加注释、日志、甚至简单缓存，但调用方只看名字就懂意图。
- 方法必须是纯判断型，不修改任何状态，也不抛异常（异常应提前处理或包装为 false）
- 参数尽量少——只传真正需要的字段，避免传整个
context对象，否则方法职责就模糊了 - 别为了“复用”强行合并逻辑：两个看似相似的条件，如果语义不同（比如一个是风控规则，一个是展示规则），就该拆成两个独立方法
警惕否定逻辑导致的双重理解成本
if (!isNotValid || !shouldNotSkip) 这种写法不是炫技，是给所有人添堵。每次读都要 mentally flip 两次，而且 IDE 很难帮你快速跳转到原始定义点。
优先用正向命名 + 正向判断。宁可多写一行取反赋值，也不要靠 ! 堆叠语义。
- 把
!user.isExpired()拆成boolean isNotExpired = !user.isExpired(); if (isNotExpired) { ... } - 更推荐直接定义
isCurrent()这样的正向方法，而非暴露isExpired()再取反 - 如果已有大量
isXxx方法且无法改名，就在调用层统一用isNotXxx变量过渡，别让否定操作散落在十几处if里
复杂条件下的调试与可观测性
上线后发现某个 if 分支没走，但本地又复现不了？大概率是某个子条件在特定数据下静默失败（比如 Integer.parseInt() 抛异常但被吞了，或 Optional.orElse(null) 导致空指针后整个条件变 false）。
别靠 print 日志硬猜。在拆分后的布尔变量赋值处加断点，或用 IDE 的“Evaluate Expression”实时查看每一步结果；生产环境则建议在关键判断点打结构化日志，记录每个子条件的输入和输出值。
- 避免在条件表达式里做副作用操作（如
cache.put(key, compute()) && cache.containsKey(key)），这会让调试完全失序 - 单元测试要覆盖所有子条件的真假组合，尤其是边界值（
null、空集合、负数、超长字符串） - 如果条件依赖外部服务返回，记得 mock 它们的各种响应状态，否则测试永远只跑通 happy path
最麻烦的从来不是写清楚条件，而是让后来人一眼看懂“这个 true 到底代表什么业务事实”。名字、拆分粒度、否定处理，三者卡住任意一环，后续补救成本都会指数级上升。
