Java中&&和||是短路运算符，左边结果能确定整体表达式时跳过右边求值，避免副作用；而&和|是非短路逻辑/位运算符，可能引发NPE或意外执行。
Java 里 && 和 || 为什么有时不执行右边？
因为它们是短路运算符：左边已能确定整个表达式结果时，右边直接跳过。比如 a && b 中，若 a 为 false，b 根本不会求值；a || b 中，若 a 为 true，b 同样被跳过。
这不只是优化，更是行为差异——如果右边有副作用（比如方法调用、变量修改），短路会直接影响程序逻辑。
- 常见错误现象：
if (obj != null && obj.getValue() > 0)安全，但换成&（非短路）就可能抛NullPointerException - 使用场景：空值检查、状态前置条件、避免昂贵计算（如数据库查询、IO）放在右侧
- 性能影响：短路在多数分支中能省一次计算，但别指望它优化循环内简单布尔变量
&、|、! 和 &&、|| 混用会出什么问题？
最典型的是把位运算符当逻辑用：& 和 | 对布尔值也做“非短路”计算，但语义上它们是位操作符，仅在 boolean 类型下被重载为逻辑运算——可读性差，且容易误用于整数上下文。
! 是唯一纯逻辑非，无短路概念，但它对引用类型不能直接用（除非配合 == null 等）。
立即学习“Java免费学习笔记（深入）”；
- 常见错误现象：
if (flag & getValue())—— 即使flag为false，getValue()仍执行；还可能被 IDE 警告 “possible accidental bitwise operation” - 参数差异：
&&/||要求两边都是布尔类型；&/|可用于整数（按位），也可用于布尔（逻辑），但编译器不区分语法意图 - 兼容性影响：Java 所有版本行为一致，但团队协作中混用会提高理解成本，Code Review 常被要求统一为
&&/||
在 if/while 条件里嵌套多个 && 和 ||，执行顺序怎么算？
优先级固定：! 最高，然后 &&，最后 ||；同级从左到右结合。但短路规则始终优先于结合性——不是“先算完左边再看右边”，而是“每一步都看是否需要继续”。
例如：a || b && c 等价于 a || (b && c)，但如果 a 为 true，b && c 整个子表达式都不会执行。
- 常见错误现象：
if (x > 0 || y > 0 && z == null)实际执行逻辑是x > 0为真就跳过后面全部，不是“x 或 y 大于 0，且 z 为空” - 使用场景：复杂条件判断中，把高概率为真/假的子表达式放左边，可提升平均性能（比如先查缓存命中，再查 DB）
- 建议加括号显式分组，尤其涉及混合运算时，别依赖优先级记忆
为什么 Boolean 包装类和 && 一起用可能 NPE？
因为 && 要求操作数是 boolean 基本类型，而 Boolean 是对象。JVM 会自动拆箱，一旦变量为 null，就触发 NullPointerException。
这不是短路的问题，是空指针在拆箱那一刻就炸了——哪怕它本该被短路跳过。
- 常见错误现象：
Boolean flag1 = null; Boolean flag2 = true; if (flag1 && flag2)→ 直接抛异常，flag2根本没机会被短路保护 - 解决方案：用
Objects.equals(flag1, Boolean.TRUE)或先判空：flag1 != null && flag1 && flag2 - 性能影响：拆箱本身开销小，但 NPE 会让逻辑中断，比性能更关键的是行为正确性
短路是 Java 的确定性规则，但它的安全边界只到基本类型为止。包装类、方法返回值、泛型推导出的类型，都可能在你以为“被短路保护”的地方悄然崩掉。
