Java运算符优先级不可靠，必须用括号明确意图；关键陷阱包括==与=混淆、&与==混用、!与==连用、&&/||低优先级导致分组错误，所有混合运算符表达式均需括号保障正确性。
Java 中运算符优先级本身不“使用”，而是必须被理解并主动规避其带来的歧义——真正可靠的做法是：不依赖记忆，用括号明确意图。
优先级最危险的几处陷阱
这些组合看似自然，却极易因优先级错配导致编译失败或逻辑错误：
- == 和 = 混用：`a = b == c` 等价于 `a = (b == c)`，不是 `(a = b) == c`；若 a 是 int、c 是 boolean，直接编译报错
- & 与 == 并存：`flags & READ_MASK == 0` 实际解析为 `flags & (READ_MASK == 0)`，而 `READ_MASK == 0` 是 boolean，无法参与位与
- ! 和 == 连用：`!obj.flag == true` 先算 `!obj.flag`（若 flag 是 boolean 合法），但语义冗余；更糟的是 `!obj == null`，实际是 `(!obj) == null`，编译失败（不能对引用取反）
- && 和 || 的低优先级：`a || b && c` 等价于 `a || (b && c)`，但人脑常误读为 `(a || b) && c`；尤其在含方法调用时，如 `isValid() || isCached() && loadFromDB()`，短路行为也受此分组影响
括号不是偷懒，是必要编码习惯
只要表达式中出现两种及以上类型运算符（比如关系+逻辑、位+关系、赋值+比较），就该加括号。这不是风格问题，而是类型安全和可维护性的基础：
- 布尔条件统一包一层：`if ((score >= 60) && (age
- 位运算永远显式分组：`(flags & PERMISSION_READ) != 0`、`(status & MASK_ERROR) == MASK_ERROR`
- 涉及 null 判断必须拆开：`obj != null && obj.isActive()`，而不是 `!obj || !obj.isActive()`（易错且难读）
- 三元运算符周围加括号：`(x > 0) ? "pos" : "neg"`，避免与赋值连用时出错，如 `s = x > 0 ? "a" : "b"` 虽合法，但 `s = x > 0 ? "a" : "b" + "c"` 会先算 `"b" + "c"`
借助工具验证你的直觉
别靠脑子猜，让 IDE 帮你“看见”分组：
立即学习“Java免费学习笔记（深入）”；
- IntelliJ 或 Eclipse 对表达式高亮时，会把子表达式（如 `b == c`）作为独立单元着色，一眼看出 `a = b == c` 中 `b == c` 被整体求值
- 鼠标悬停在运算符上，部分 IDE 显示“binding precedence”，提示当前运算符相对于邻接运算符的结合顺序
- 写完复杂条件后，右键 → “Extract Variable”，把子表达式单独命名（如 `boolean hasPermission = (flags & READ) != 0`），既提升可读性，又彻底消除优先级干扰
团队协作中的务实约定
优先级规则无法强制，但括号规则可以落地：
- 代码规范明文规定：“所有含两个及以上运算符的表达式，必须用括号明确结合顺序”
- CI 流水线接入静态检查（如 Checkstyle 的 `ExplicitParentheses` 规则），自动拦截 `x & y == 0` 类写法
- Code Review checklist 包含一项：“是否每个布尔表达式都可被括号无歧义地切分？”
