java中判断数值是否在闭区间内应直接写a
Java中判断数值是否在闭区间内：别用 && 连两个比较
直接写 a 最简洁、最安全，JVM 会短路且可读性不输任何工具方法。很多人下意识拆成 <code>x >= a && x ，其实顺序无关紧要，但把边界值放两边、变量居中（<code>a 风格的等价写法）更贴近数学直觉，也更容易一眼识别区间方向。
- 不要封装成
isBetween(x, a, b)方法——除非项目强制统一风格或需处理null/NaN - 整数、
long、double都适用；但double要小心浮点误差，比如0.1 + 0.2 == 0.3是false，此时区间判断可能意外失败 - 如果 a > b，表达式自然返回
false，无需额外校验——这是优势，不是 bug
使用 Guava 或 Apache Commons 的 Range：适合复杂场景，不是为简单判断而生
像 Range.closed(5, 10).contains(x) 看着优雅，但引入依赖只为一行逻辑，得不偿失。它真正有用的地方是：需要复用同一个范围多次判断、要做范围合并/交集、或要支持开闭混合（如 [5, 10)）。
-
Range对象不可变，线程安全，但每次调用都新建实例（哪怕参数相同），有轻微 GC 开销 -
Range.contains()对double同样不处理精度问题，不会比原生比较更“准” - Android 项目慎用 Guava（方法数爆炸），
commons-lang3的ObjectUtils不提供区间工具，别找错包
避免用 Math.min/max 做区间判断：语义错位且易出错
有人写 x >= Math.min(a, b) && x 想兼容 a/b 顺序，这反而暴露了设计漏洞——如果业务上 a 必须 ≤ b，那应该在输入阶段校验，而不是在判断时补救。
- 这种写法掩盖了参数含义混乱的问题，后续维护者看不懂 a 和 b 到底哪个是下界
-
Math.min/max对NaN返回NaN，导致整个表达式结果为false，但你未必意识到是NaN搞的鬼 - 性能上多两次函数调用，对热点代码有微小影响（不过通常可忽略）
边界值类型不一致时的隐式转换陷阱
写 5L （<code>x 是 int）看似没问题，但若 x 是 byte 或 short，比较前会先提升为 int，而 5L 是 long，这时整个表达式会把 x 也转成 long——通常无害，但若涉及大数值或自定义数值类，可能触发意料外的 valueOf 或构造行为。
立即学习“Java免费学习笔记（深入）”；
- 保持字面量和变量类型一致：
x是int就全用int字面量（5而非5L） - 泛型数值类（如
BigDecimal）必须用compareTo()，会编译失败 - 枚举序号比较（
enum.ordinal()）可以照常用，但语义上不如用 <code>EnumSet.range()清晰
