会跳，短路逻辑运算符在if条件中只要左操作数能确定整个表达式结果，就跳过右操作数执行；这是防止空指针、控制副作用的关键机制，而非单纯性能优化。
短路逻辑运算符在 if 条件里到底跳不跳过右边？
会跳，而且这是它的核心价值——只要左边能确定整个表达式结果，右边根本不会执行。比如 && 左边是 false，整个结果必为 false，右边连看都不看；|| 左边是 true，整个结果必为 true，右边直接跳过。
这不只是“省点计算”，而是防止副作用或空指针的关键机制。常见错误是写成：if (obj != null && obj.getName().length() > 0)，如果不用 && 而用 &，obj 为 null 时就会抛 NullPointerException。
-
&&和||是布尔操作符，只接受boolean类型，不能用于整数或对象 -
&和|是位运算符（对布尔类型也支持），但不短路，两边一定执行 - 如果右边有日志、修改状态、数据库查询等逻辑，用错运算符会导致意料外的执行或跳过
什么时候不该依赖短路？
当右边的表达式本就该无条件执行时，硬用 && 或 || 反而掩盖意图、增加维护成本。比如两个独立校验都要触发：
validateUserInput();<br>validateNetworkConnection();<br>if (validateUserInput() && validateNetworkConnection()) { ... }
看起来没问题，但一旦 validateUserInput() 返回 false，第二个校验就被跳过——而你可能希望它始终运行（比如收集所有错误）。这时候应该分开调用，再用普通变量组合判断。
- 短路不是“流程控制语法糖”，它本质是表达式求值策略
- 把副作用逻辑塞进条件表达式里，会让代码难以单测和调试
- IDE 有时会警告 “Condition is always true/false” —— 很可能是短路让某分支永远不可达
嵌套条件里短路行为还可靠吗？
可靠，但优先级容易误判。Java 中 && 优先级高于 ||，所以 a || b && c 等价于 a || (b && c)，不是 (a || b) && c。实际中常有人加错括号，导致短路时机错乱。
例如：if (user.isAdmin() || user.isGuest() && user.hasValidSession())，本意是“管理员 或 （访客且有有效会话）”，但如果写成 if (user.isAdmin() || user.isGuest() && user.hasValidSession()) 少了括号，逻辑没错；可一旦改成 if (user.isAdmin() && user.isPremium() || user.isGuest())，就变成“（管理员且高级用户）或访客”，而非“管理员且（高级用户或访客）”。
- 复杂条件一律加括号，别靠记忆优先级
- 短路发生在每个
&&/||节点上，不是整条 if 表达式只看第一个 - 用 extract method 拆分长条件，比堆括号更利于理解和测试
性能影响大不大？
几乎没有。现代 JVM 对短路逻辑做了充分优化，&& 和 || 的开销几乎等于零。真正影响性能的是右边那个被跳过的函数本身——比如它本要查一次数据库，跳过就省下几十毫秒；但如果你为了“看起来快”而强行把 list.size() > 0 放左边、把 list.get(0).equals("x") 放右边，却忘了 list 是 LinkedList，那 size() 是 O(n)，反而更慢。
- 短路本身不耗资源，但“避免执行”带来的收益取决于被跳过操作的代价
- 不要为微秒级差异提前优化，先确保逻辑正确、边界清晰
- 在循环内高频使用短路时，注意 JIT 是否已将条件判定内联——一般不用管，除非压测发现瓶颈真在这儿
短路逻辑最危险的不是用错，而是用得太顺手，以至于忘了右边那段代码本来就不该出现在条件里。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
