用 % 运算符判断奇偶最直接可靠：n % 2 == 0 为偶数，否则为奇数；它对所有整数类型及负数均符合数学定义，且无需 Math.abs() 或位运算，兼顾正确性、可读性与JVM优化。
用 % 运算符判断奇偶是最直接的方式
Java 里判断奇偶，核心就一条：看除以 2 的余数是不是 0。用 %（取模运算符）最稳妥，n % 2 == 0 就是偶数，否则是奇数。
注意别用 / 或 == 比较浮点结果，比如 n / 2.0 == (int)(n / 2.0) —— 不仅慢，还可能因浮点精度出错；也别用位运算 (n & 1) == 0 去替代，虽然对正整数有效，但负数时行为反直觉（比如 -3 & 1 是 1，但人通常仍认为“-3 是奇数”，这点没错，可代码可读性差，且容易在边界场景误判）。
-
%对负数也符合数学定义：-4 % 2是 0（偶数），-5 % 2是 -1（非 0，即奇数） - 所有整数类型（
int、long、short、byte）都支持% - 如果变量是
Integer包装类，先确保不为null，否则会抛NullPointerException
遇到 Math.abs(n) % 2 == 1 这种写法要警惕
有人想“统一转正再判断”，写成 Math.abs(n) % 2 == 1 判断奇数。这在绝大多数情况下能跑通，但有个致命例外：Integer.MIN_VALUE。
Math.abs(Integer.MIN_VALUE) 结果还是 Integer.MIN_VALUE（因为补码溢出），而 Integer.MIN_VALUE % 2 == 0，所以 Math.abs(Integer.MIN_VALUE) % 2 == 1 返回 false —— 但 Integer.MIN_VALUE 实际上是偶数，逻辑没错，可这个写法让人误以为它“不能处理负数”，其实是它根本没正确处理极端值。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 直接用
n % 2 == 0就行，不需要Math.abs() - 如果非要封装成工具方法，别加多余转换，更别用
abs掩盖问题 - 单元测试里记得覆盖
Integer.MIN_VALUE和Integer.MAX_VALUE
在循环或高频调用中，% 性能不是瓶颈
有人担心 % 比位运算慢，想用 (n & 1) == 0 替代。实测在现代 JVM（JDK 8+）上，HotSpot 会对 n % 2 做常量折叠和强度削减，最终生成的汇编指令和 & 1 几乎一样快。
真正影响性能的是可读性和维护成本：用 & 1 需要开发者理解二进制和补码，而 % 2 直观表达“能否被 2 整除”的语义。团队协作中，后者出错率更低。
- 除非你在写 JNI 或极底层的数值计算库，否则别为这点微秒差异牺牲可读性
- 如果真做了基准测试（比如 JMH），发现
%拖慢整体逻辑，那问题大概率不在这里，而在 IO、对象分配或锁竞争 -
switch (n % 2)在 JDK 14+ 支持模式匹配前不推荐，因为%结果是 0 或非 0，不是严格的 0/1
输入可能是字符串或用户输入时，先校验再判断
算法练习常假设输入是合法整数，但真实场景中，你拿到的可能是 String，比如表单提交的 "123" 或 "abc"。这时候直接 Integer.parseInt(s) % 2 会抛 NumberFormatException。
不要用 try-catch 包裹整个判断逻辑来“兜底”——异常开销大，且掩盖了输入校验缺失的问题。
- 先用正则
s.matches("-?\d+")粗筛（注意不能匹配"+123"，如需支持得调整） - 再用
Integer.parseInt(s)转换，捕获NumberFormatException并返回明确错误提示 - 如果数字可能超
int范围，改用BigInteger：用new BigInteger(s).mod(BigInteger.TWO).equals(BigInteger.ZERO)
奇偶判断本身很简单，难的是它常作为更大逻辑的一环嵌在输入处理、数据清洗或条件分支里。最容易被忽略的，是把“判断奇偶”当成孤立操作，忘了它前面的数据来源是否可信、类型是否稳定。
