布尔表达式越嵌套，越容易写错 !a && !b 还是 !(a || b)
德·摩根定律不是数学题，是日常写 if 时踩坑的高发区。比如你本想排除两种非法状态，却写成 if (!isValid && !isReady)，结果逻辑变成“两个都无效才执行”，而真实需求可能是“只要有一个无效就跳过”——这恰恰该用 if (!(isValid && isReady))。
常见错误现象：NullPointerException 隐蔽出现，因为嵌套否定让短路逻辑变难读；或者测试覆盖不到边界，比如 a=false, b=true 时分支没走。
- 优先把否定提到最外层：把
!a || !b改成!(a && b)，语义更贴近业务（“不满足全部条件”） - 避免连续否定：像
!!(a || b)不仅冗余，还可能掩盖a或b是null的问题 - Java 中
&&和||是短路运算，但加了!后，人脑解析顺序容易和执行顺序错位——建议先画真值表，再动笔
用 Objects.nonNull() 替代手写 != null 否定判断
很多人写 if (obj != null && obj.isActive())，看着没问题，但一旦改成否定逻辑，比如“跳过空或非激活对象”，就容易写出 if (obj == null || !obj.isActive()) continue; —— 这里 obj == null 在前是安全的，可如果顺序反了，!obj.isActive() 就会 NPE。
德·摩根本身不解决 NPE，但它迫使你重新组织条件结构，这时顺手换成标准工具类更稳。
立即学习“Java免费学习笔记（深入）”；
-
Objects.nonNull(obj)比obj != null更明确表达“需要非空”，且在静态分析工具中更容易被识别 - 配合
Optional使用时，optional.filter(x -> x.isValid()).isPresent()比optional.isPresent() && optional.get().isValid()更安全，也更符合德·摩根的“先抽象再否定”思路 - 注意
Objects.requireNonNull()是抛异常，不是布尔判断，别误用在条件表达式里
Stream.filter() 里写否定条件，别硬套 ! 前置
写 list.stream().filter(!User::isActive).collect(...) 会编译失败——方法引用不能直接加 !。有人改用 u -> !u.isActive()，看似解决了，但可读性差，而且容易和 u -> u.isActive() == false 混淆（后者在 Boolean 包装类场景下有空指针风险）。
这时候德·摩根提示你：与其否定谓词，不如换个正向谓词名，或提前归一化状态。
- 定义清晰的谓词方法：比如
static boolean isInactive(User u) { return u != null && !u.isActive(); }，然后直接filter(UserUtils::isInactive) - 如果必须动态组合，用
Predicate的negate()方法：Predicate<user> active = User::isActive; list.stream().filter(active.negate()).collect(...)</user>，它内部做了空安全包装，比手写!更可靠 - 警惕
negate()的闭包陷阱：如果原始Predicate捕获了外部变量，negate()不会改变其执行时机或异常行为
复杂条件重构时，抽成 private boolean 方法比堆 ! 更管用
当一个 if 判断包含 3 个以上子条件、还夹着否定，比如 if (!(user.hasRole("ADMIN") && user.isVerified() && !user.isLocked()))，这不是德·摩根能救的——这是设计信号：这个逻辑已经超出单行表达式的承载能力。
此时强行用德·摩根变形，只会让代码从“难读”变成“难懂”。真正该做的是把意图显性化。
- 抽出方法名要带业务语义，比如
canAccessAdminPanel()，而不是isNotForbidden() - 方法体内仍可使用德·摩根优化子表达式，但对外只暴露一个清晰入口
- IDE 重命名时，只有方法名能批量更新；散落在各处的
!(a && b && !c)修改成本高、易遗漏
德·摩根真正起作用的地方，从来不在超长一行里打转，而在你决定把哪段逻辑拎出来、怎么命名、以及是否值得加单元测试的时候。
