Java里 && 和 || 为什么有时不执行右边？
因为它们是短路运算符——左边结果已能确定整个表达式真假时，右边直接跳过。这不是bug，是设计行为。
比如 if (obj != null && obj.isValid())，如果 obj 是 null，obj.isValid() 根本不会调用，避免空指针。但反过来，if (obj.isValid() && obj != null) 就会崩。
- 用
&&做安全判空时，把可能为null或false的条件放左边 - 用
||做默认值兜底时（如str != null || str.isEmpty()），注意左边为true就不再看右边 - 如果右边有副作用（比如方法里改了状态、打了日志），短路会导致它偶尔不触发——这是最常被忽略的坑
& 和 | 在布尔上下文中到底该不该用？
能用，但几乎不该用。它们是位运算符，在布尔表达式里会强制计算两边，且优先级比 &&/|| 高，容易引发意料外的结合顺序。
比如 if (a & b == c) 实际等价于 if (a & (b == c))，而你本意可能是 (a & b) == c；换成 if (a && b == c) 就清晰得多。
立即学习“Java免费学习笔记（深入）”；
- 只有明确需要两边都执行（比如必须触发两个方法的副作用），才考虑
&或| - 绝大多数业务逻辑中，用
&&/||更安全、更符合直觉 - 在
if、while、三元表达式这些地方，坚持用短路版本
布尔表达式里混用 == 和 equals() 会出什么错？
对引用类型（比如 String、自定义对象）用 == 比较，实际比的是内存地址，不是内容。哪怕两个字符串字面值一样，也可能返回 false。
常见错误：if (str == "abc") —— 这只在 str 恰好指向字符串常量池里的 "abc" 时才成立；换成 if ("abc".equals(str)) 就稳了，还能防 null。
- 永远优先用
"常量".equals(变量)而不是变量.equals("常量") - 基本类型（
int、boolean等）只能用==，用equals()会编译不过 -
Boolean包装类之间比较更要小心：两个new Boolean(true)用==是false，用.equals()才是true
嵌套太多逻辑运算符时，怎么避免括号写错或读不懂？
没有银弹，但有两个硬约束：一是别靠记忆优先级，二是别让单行表达式承担太多语义。
Java 中 ! 最高，然后是 &，再是 ^，最后是 |，而 && 和 || 优先级更低——但没人真去记。出问题的往往不是算错，而是别人（或三天后的你自己）看不懂。
- 只要超过两个操作数，就加括号，哪怕看起来“没必要”
- 把复杂判断拆成带名的布尔变量：
boolean hasPermission = user.isAdmin() && resource.isPublic(); - 遇到
!a && !b || c这种，先按德·摩根律转成!(a || b) || c，再拆；否则很容易漏掉否定范围
== 到底比的是啥」——这两个点一旦出错，问题往往藏得深、复现难。 
