Java中&&和||叫“短路”运算符，因为它们在确定结果后立即停止计算右表达式，可避免空指针等错误；&和|是不短路的位运算符，布尔上下文中仍会执行两边；混用==和equals()易导致逻辑错误或NPE；复杂条件务必加括号或拆解为语义变量。
Java里&&和||为什么叫“短路”运算符
因为它们在确定整体结果后，**立刻停止计算右边表达式**。比如 a && b 中，若 a 为 false，整个结果必为 false，b 根本不会执行；同理，a || b 中若 a 为 true，b 就被跳过。
这不只是性能优化，更是避免副作用或运行时错误的关键：
- 防止空指针：
obj != null && obj.toString().length() > 0—— 若obj为null，obj.toString()不会调用 - 避免非法状态：
list != null && !list.isEmpty() && list.get(0) > 5—— 前两个条件不满足时，get(0)不会触发 - 慎用带副作用的表达式：
flag = true || doSomething()中，doSomething()永远不会执行
&和|在布尔上下文中到底有什么用
它们是**位运算符**，但在 boolean 类型上也合法，且**不短路**：左右两边一定都会求值。日常逻辑判断中几乎不用，但有特定场景：
- 需要强制执行右侧副作用（极少见，通常说明设计有问题）
- 做布尔掩码组合（如权限校验中多个标志位的统一判断）
- 单元测试中模拟“两边都必须执行”的行为，用于验证副作用是否发生
示例：boolean a = false; boolean b = true; boolean result = a | b; → b 仍会被计算，即使 a 是 false。注意：这里用 | 而非 ||，语义完全不同。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
布尔表达式里混用==和equals()容易出什么错
这不是逻辑运算符本身的问题，但常出现在 &&/|| 的左右操作数中，导致逻辑失效：
-
String s1 = "hello"; String s2 = new String("hello"); if (s1 == s2 && ...)→false，整条逻辑可能意外跳过 -
Integer a = 128, b = 128; if (a == b && ...)→ 在 -128~127 外缓存失效，==返回false，而equals()才正确 -
Boolean flag = null; if (flag == true && ...)→ 抛NullPointerException；应写成Boolean.TRUE.equals(flag)或先判空
复杂条件链中优先级和括号怎么用才不踩坑
Java 中 ! 优先级最高，接着是 &&，最低是 ||。但人脑记不住优先级，尤其混合使用时：
-
a || b && c等价于a || (b && c)，不是(a || b) && c -
!a && b || c等价于((!a) && b) || c，但可读性极差 - 只要条件超过两个子表达式，**一律加括号**——不是为了编译通过，而是让后续维护者一眼看懂意图
- 更推荐拆解：把每个原子条件提取为有语义的
boolean变量，例如isValidUser、hasPermission，再组合
真正难的不是语法，是把业务规则准确映射到布尔结构里；多一层括号，少三天 debug。
