Arrays.binarySearch搜不到明明存在的元素是因为它仅对已排序数组有效；未排序或降序数组（未配对应Comparator）会导致结果不可靠，返回负数表示插入点编码而非简单“未找到”。
Arrays.binarySearch 为什么搜不到明明存在的元素
因为 Arrays.binarySearch 只在**已排序数组**上保证正确性；未排序时返回值无意义，可能为负数、0，甚至“碰巧”对上某个索引——但这纯属巧合，不可依赖。
- 常见错误现象：
Arrays.binarySearch(arr, 42)返回-1，但Arrays.asList(arr).contains(42)是true - 根本原因：二分查找每次比较后直接舍弃一半区间，前提是数组单调（升序/降序），否则“舍弃”会漏掉目标
- 使用场景仅限：确认数组已按自然序或指定
Comparator排好序，且后续无写入干扰排序状态 - 别试图“先查再排”——排序是 O(n log n)，查是 O(log n)，合起来不如线性扫描 O(n) 来得实在
升序 vs 降序数组，binarySearch 能不能直接用
默认只支持升序；传入降序数组会导致结果完全不可预测，Arrays.binarySearch 不做任何顺序校验。
- 升序安全：用
Arrays.binarySearch(arr, key)或Arrays.binarySearch(arr, key, comparator)，其中comparator必须与排序时用的一致 - 降序必须显式传
Comparator：比如Arrays.binarySearch(arr, key, Collections.reverseOrder())，且前提是数组真用这个 comparator 排过序 - 参数差异关键点：
comparator不仅影响比较逻辑，还决定“中点选择”后的分支方向——错配就等同于乱跳 - 性能无额外开销，但兼容性极差：JDK 8+ 才支持
Comparator版本的binarySearch对基本类型数组无效（只能用包装类数组）
返回值负数到底代表什么
负数不是“没找到”的简单标记，而是带位置信息的插入点编码，必须用公式还原。
- 若返回值 ≥ 0：就是目标元素的索引，可直接用
- 若返回值 -(return_value) - 1，例如返回
-5，表示应插入到索引4 - 容易踩的坑：直接判断
result 就认为“不存在”，却忽略插入点可用于维护有序结构（如实现 <code>TreeSet风格的插入逻辑） - 不要手写
if (result ——这是错的，必须用原值参与运算
基本类型数组和对象数组的差异陷阱
基本类型数组（int[]、double[] 等）不支持自定义 Comparator，且 null 值直接抛 NullPointerException。
立即学习“Java免费学习笔记（深入）”；
- 对象数组（
Integer[]、String[]）才能用Comparator版本，也才能处理null（取决于 comparator 实现） - 基本类型数组调用
binarySearch时，key 类型必须严格匹配：用int查int[]，不能用long或Integer（会触发自动装箱，查的是对象数组） - 性能影响：基本类型版本是纯数组下标操作，无对象开销；对象版本涉及引用比较、可能触发 GC，但差别通常可忽略
- 兼容性注意：Android API 26+ 才完整支持所有重载，低版本对
double[]等某些类型可能缺失方法签名
排序这件事没法偷懒——binarySearch 的契约里，“已排序”是前提条件，不是可选优化。很多人卡在返回负数上反复调试，其实问题早发生在调用前那行没写的 Arrays.sort()。
