Java中&&是短路与，&是按位与（布尔上下文中为非短路逻辑与）；&&在左操作数为false时跳过右操作数执行，&则始终计算两边，故条件判断应优先用&&以保障安全和效率。
Java 中 && 是短路与，& 是按位与（也作逻辑与，但不短路）。关键区别在于：当左边表达式已能确定整个结果时，&& 会跳过右边表达式的执行；而 & 总是两边都计算，不管左边结果如何。
短路求值：&& 只在必要时才算右边
对于 a && b，JVM 先求值 a：
- 如果
a为false，整个表达式必为false，b完全不执行（跳过副作用） - 如果
a为true，才继续求值b，最终结果取决于b
例如：list != null && !list.isEmpty() 安全，因为若 list 为 null，就不会调用 isEmpty()，避免空指针异常。
& 运算符：左右都执行，无短路行为
a & b 无论 a 是 true 还是 false，b 都会被求值：
立即学习“Java免费学习笔记（深入）”；
- 这在布尔上下文中等价于逻辑与，但失去短路保护
- 常用于需要强制执行右侧逻辑（比如日志、状态更新）的场景，但需谨慎
- 也用于整数的按位与运算（如
flag & MASK），此时语义完全不同
例如：isValid() & logAttempt() 即使 isValid() 返回 false，logAttempt() 仍会被调用。
什么时候该用哪个？
日常条件判断一律优先用 &&：
- 安全：防止空指针、资源未初始化等运行时异常
- 高效：避免无意义的计算（如远程调用、复杂校验）
- 清晰：符合多数人对“逻辑与”的直觉预期
仅在明确需要两边都执行时才考虑 &，比如调试计数、多条件副作用合并，或进行位运算。注意：混用容易引发隐蔽 bug，建议加注释说明意图。
一个易错点：& 在布尔表达式中不是“更严格”，而是“更危险”
新手有时误以为 & 比 && “更保险”或“更彻底”，其实恰恰相反：
-
&不提供安全保障，反而可能触发本应避免的异常 - 它没有额外语义优势，只是放弃优化机会
- 除非你真需要副作用，否则用
&做逻辑判断通常是设计缺陷
编译器不会报错，但静态分析工具（如 IntelliJ 或 SonarQube）常会警告布尔上下文中使用 &。
