排查Java运算符优先级Bug的核心是识别“表达式被错误分组导致类型或逻辑失配”，应通过括号显式断句、IDE高亮、字节码验证及拆分变量等手段主动防御，而非死记优先级表。
排查 Java 运算符优先级引发的 Bug，核心不是背优先级表，而是识别“表达式被错误分组后类型或逻辑失配”的现象。这类 Bug 往往不报编译错误，却在运行时返回诡异结果，或直接编译失败提示 incompatible types、bad operand types 等模糊信息。
看编译错误提示反推实际分组
编译器不会说“你忘了括号”，而是暴露分组后果：
-
if (flags & MASK == 0)→ 报错bad operand types for binary operator '&'：说明编译器把MASK == 0先算成了boolean，再试图和int flags做位与 -
obj instanceof String == null→ 报错incomparable types: boolean and <nulltype>：因为实际是(obj instanceof String) == null，左边是 boolean，不能和 null 比较 -
a = b == c看似想赋值再比较，但实际等价于a = (b == c)，若a是int而b == c是boolean，就触发类型不匹配
用括号显式断句，而不是赌记忆
只要表达式含两种及以上运算符类别（如算术+关系、关系+逻辑、位运算+比较），一律加括号：
- 位操作判断：写
(flags & READ_MASK) != 0，不写flags & READ_MASK != 0 - 混合条件：写
if ((x > 0) && (y < 10))，不依赖&&优先级低于>的事实 - 三元嵌套：写
result = (a > b) ? (c + d) : (e - f)，避免a > b ? c + d : e - f因结合性产生歧义
借助 IDE 和字节码验证真实执行逻辑
人工推导易出错，工具能给出确定答案：
立即学习“Java免费学习笔记（深入）”；
- IntelliJ / Eclipse 会高亮子表达式：把光标停在
a == b & c的b & c上，高亮范围即编译器认定的运算单元 - 用
javap -c查看字节码：例如a || b && c编译后，会先计算b && c再与a做ifne跳转，证实分组为a || (b && c) - 对存疑表达式单独提取变量：把
list.get(i) + 1 < max && flag拆成int val = list.get(i) + 1;+if (val < max && flag)，既清晰又可调试
盯住高频危险组合，提前拦截
以下几类混合最常翻车，写代码时应本能加括号或重构：
-
&、|、^和==、>混用：位掩码判断必须括起来 -
+出现在数字和字符串之间：如"score: " + a + b > 100实际是("score: " + a + b) > 100（字符串不能比大小），应写"score: " + (a + b) -
!和==相邻：!a == b是(!a) == b，真要取反整个比较得写!(a == b) -
instanceof后接逻辑运算：obj instanceof String && obj.length() > 0安全，但obj instanceof String || obj != null有风险，建议统一写成(obj instanceof String) || (obj != null)
