Java中判断偶数首选n % 2 == 0，它语义清晰、支持负数且安全；位运算(n & 1) == 0虽快但可读性差，需注意括号和类型，对BigInteger等需用专用方法。
用 % 判断偶数最直白，但要注意负数
Java 中最常用的是 n % 2 == 0。它符合数学直觉，可读性强，绝大多数场景下推荐直接用。但关键陷阱是：负数取余结果仍为负——比如 -4 % 2 是 0（没问题），但 -5 % 2 是 -1，所以 -5 % 2 == 0 为 false，逻辑正确；真正容易出错的是有人误写成 n % 2 == 1 来判奇数，这在负数时完全失效。
使用建议：
- 判偶数统一用
n % 2 == 0，不要依赖余数是否等于 1 - 如果输入可能为
Integer.MIN_VALUE，%仍安全（不会溢出） - 对浮点数不适用——
%在 Java 中支持double，但“偶数”概念仅针对整数，应先确保类型是int或long
用位运算 (n & 1) == 0 更快，但只适用于非负整数补码表示
位运算是通过检查二进制最低位是否为 0 来判断偶数：n & 1 得到的是最低位的值（0 或 1），所以 (n & 1) == 0 即为偶数。它比取余快，因为不涉及除法指令，在底层更轻量。
但必须注意：Java 整数是补码表示，而 & 1 对负数也有效——例如 -4 & 1 是 0，-5 & 1 是 1，所以该表达式对负数同样能正确判断奇偶性。很多人误以为它“不支持负数”，其实是支持的。
立即学习“Java免费学习笔记（深入）”；
真正限制在于：
-
long类型要用(n & 1L) == 0，否则1是int，可能触发隐式类型转换警告 - 如果
n是包装类型（如Integer），需先解包，避免空指针；null & 1会直接抛NullPointerException - 代码可读性下降，团队协作中需确认成员理解位运算语义
性能差异微乎其微，别为这点速度牺牲可维护性
在现代 JVM（JDK 8+）上，% 2 常被 JIT 编译器自动优化为位运算，实测百万次循环下两者耗时差异通常在纳秒级。除非你在高频数学计算核心（如图形渲染、密码学循环），否则优化这里毫无意义。
更值得警惕的是隐蔽成本：
- 用
& 1可能误导后续维护者去套用到% 3场景，但n & 2 == 0并不等价于n % 3 == 0 - 某些静态分析工具（如 SonarQube）会对无括号的
n & 1 == 0报警，因为&优先级低于==，实际执行的是n & (1 == 0)—— 必须写成(n & 1) == 0 - 在调试器里，
n & 1的中间值不如n % 2直观，尤其对新同学
遇到 BigInteger 或自定义数值类型怎么办
BigInteger 不支持 & 或 % 运算符重载，必须调用方法：bigInt.remainder(BigInteger.TWO).equals(BigInteger.ZERO) 是标准写法；bigInt.testBit(0) 等价于 (n & 1) != 0，所以偶数判断要写成 !bigInt.testBit(0)。
自定义数值类（如封装了精度控制的 FixedPoint）不能直接套用位运算或取余，必须暴露明确的 isEven() 方法，内部根据其存储格式决定实现逻辑——这时候硬套 & 1 或 % 2 会彻底跑偏。
本质上，偶数判断不是语法技巧问题，而是语义归属问题：它属于“整数数学属性”，不是“二进制操作技巧”。类型越抽象，越要回归语义本身。
