短路运算符仅在左操作数确定整体结果时跳过右表达式：&&左为false、||左为true时生效；需确保左操作数稳定快速且分布利于提前终止，避免异常、副作用或耗时操作置于左侧。
短路运算符能跳过右边表达式，但只在特定条件下生效
短路不是“自动优化”，而是由左操作数的值强制触发的执行跳过行为：&&在左操作数为false时跳过右操作数；||在左操作数为true时跳过右操作数。这意味着：左边必须先求值，且它的结果决定了右边是否运行。
常见误解是认为“写成链式就一定省事”，但若左边总为true（如flag == true && expensiveCall()），右边永远执行，毫无短路收益。
-
&&适合把“高失败率、低开销”的条件放左边（如obj != null、list.size() > 0） -
||适合把“高成功率、低开销”的条件放左边（如isCached()、config.isDebug()） - 非布尔类型参与时（如 JavaScript 中
str && str.trim()），短路仍生效，但返回的是值而非true/false，需注意逻辑一致性
把耗时操作放右边，但得确保左边真能拦住它
很多人把file.exists() && readFile(file)当范例，却忽略file.exists()本身也可能抛异常（如权限不足、路径非法），此时短路失效，readFile()不会被跳过，但程序已在前一步崩溃。
真正起效的前提是：左边表达式足够稳定、执行快、且结果分布利于提前终止。
- 避免把可能抛异常的检查放左边，除非你明确捕获并处理——比如
Files.exists(path)比path.toFile().exists()更健壮 - 数据库查询、HTTP 调用、正则匹配这类操作，绝不能放在左边；即使加了缓存，也要确认缓存命中率足够高
- 循环内慎用短路链：JIT 可能因分支预测失败而降级，实测
a && b && c && d()不如拆成两个if清晰且高效
副作用藏在右边时，逻辑会悄无声息地坏掉
短路最隐蔽的坑不是性能，而是行为不一致。当你写isValid() && counter++ > 0，counter++根本不会执行——这不是 bug，是语言规范。但调试时断点打在counter++上永远不会命中，容易误判逻辑漏执行。
类似情况还包括日志打印、状态标记、资源申请等隐式变更。
- 含副作用的表达式一律不要塞进短路右侧，哪怕它“看起来很轻”
- 需要条件触发副作用时，显式写出
if (isValid()) { counter++; ... } - 函数调用本身有副作用（如
logAndReturn(true)）也属于高危，应视为“不可短路依赖”
Java 里别用&和|替代&&和||来“强制求值”
有人为了确保右边一定执行，改用&或|，这是危险操作：它们不光取消短路，还会改变求值顺序语义，且在布尔上下文中失去可读性。
例如obj != null & obj.getName().length() > 0，一旦obj为null，直接NullPointerException；而&&版本天然安全。
-
&和|应仅用于位运算（如flags & READ_PERMISSION）或明确需要两边都执行的布尔场景（极少见） - 若真需要“无论怎样都执行右边”，用分号隔开：先算左边，再根据结果决定是否执行右边，意图清晰、无歧义
- 静态分析工具（如 SpotBugs）通常会对
boolean & boolean发出警告，把它当成潜在缺陷
实际写多重条件时，最易被忽略的是：短路只解决“执行跳过”，不解决“解析开销”或“闭包捕获”。哪怕expensiveFunction被短路跳过，只要它出现在表达式里，其所在闭包就已被创建、变量已捕获——这点在 React 渲染或事件回调中尤其关键。
