Java逻辑运算符组合使用详解

Java逻辑运算严格从左到右、按短路原则执行，不因优先级跳算；三元运算符优先级低于&&和||，混用须加括号；Boolean对象参与运算可能触发空指针异常。

Java里&&和||混用时，求值顺序怎么判断

Java严格按从左到右、短路原则执行逻辑运算，不是看优先级高低就跳着算。比如a && b || c，先算a && b，结果为true才继续算c；如果a为false，整个&&直接短路，b不执行，接着算||右边的c。

容易误以为&&优先级高于||就一定先完整算完&&子表达式——其实只要左边已能确定整体结果，就停。

• false && someMethod() || true → someMethod()根本不会调用
• true || dangerousCall() && anotherCall() → dangerousCall()和anotherCall()全被跳过
• 想强制分组必须加括号：a && (b || c) 或 (a && b) || c

嵌套三元运算符配合逻辑运算符的写法陷阱

三元运算符?:优先级低于&&和||，不加括号极易出错。例如flag1 && flag2 ? "A" : "B"等价于(flag1 && flag2) ? "A" : "B"，但flag1 || flag2 ? "A" : "B"实际是(flag1 || flag2) ? "A" : "B"，看起来没问题，一旦混入&&就危险：

boolean a = true, b = false, c = true;
String s = a || b && c ? "OK" : "FAIL"; // 等价于 a || (b && c)，结果是 "OK"

但如果本意是(a || b) && c，漏括号就会逻辑错位。更复杂时如cond1 ? val1 : cond2 && cond3 ? val2 : val3，必须用括号明确每段三元的边界。

• 三元运算符只绑定最近的条件表达式，不跨逻辑运算符“感知”范围
• IDE通常会警告“Conditional expression with &&/|| inside”，别忽略
• 可读性差的嵌套建议拆成if-else，尤其涉及方法调用或副作用

布尔包装类Boolean参与逻辑运算的空指针风险

用Boolean对象而非boolean原始类型时，&&和||会触发自动拆箱，遇到null直接抛NullPointerException：

Boolean flag1 = null;
Boolean flag2 = true;
if (flag1 && flag2) { ... } // 运行时报错：Cannot unbox null

这不是语法错误，编译能过，但运行时崩溃。常见于从Map、JSON或数据库取值后未判空就直接参与逻辑组合。

• 安全写法是显式判!= null再用：flag1 != null && flag1 && flag2
• 或统一转原始类型：Objects.requireNonNullElse(flag1, false)
• Spring等框架的@RequestParam(required = false)若映射为Boolean，更要警惕默认null

在Stream.filter()里组合多个布尔条件的推荐方式

写stream.filter(x -> x.isValid() && x.isReady() && !x.isArchived())看似自然，但每个方法都可能有副作用或耗时。一旦前一个条件为false，后续调用就被短路跳过——这是优势，但也是隐式依赖。

如果某个方法抛异常（比如isReady()查数据库失败），而你希望它总被执行以收集日志，就不能靠&&串联。

• 需要“全部执行+汇总结果”时，改用独立变量：

stream.filter(x -> {
    boolean valid = x.isValid();
    boolean ready = x.isReady(); // 即使 valid==false 也会执行
    boolean archived = x.isArchived();
    return valid && ready && !archived;
})

• 条件多且复用时，提取为静态方法比长表达式更易测、易调试
• 避免在filter里调用非纯函数（如System.currentTimeMillis()），时间漂移会导致结果不稳定

逻辑运算符本身没秘密，难的是在真实场景中预判副作用、空值、执行时机和可维护性。括号、拆箱、短路——这三个点，漏掉任何一个都可能让条件表达式在某个凌晨三点悄悄失效。