Collections.binarySearch要求List必须已排序，否则结果不可预测；因二分查找依赖有序性划分区间，未排序时无法确定搜索方向，JDK不校验排序直接执行，可能返回错误索引或无意义负值。
Collections.binarySearch 要求传入的 List 必须是已按自然顺序或指定比较器排序的，否则结果不可预测——不是抛异常，而是返回任意负数或错误索引，这正是“未定义行为”的典型表现。
为什么未排序 List 会导致问题
二分查找依赖“中间元素能划分搜索区间”的前提。若列表无序，每次取中点比较后无法确定目标在左半还是右半，算法逻辑崩塌。JDK 不做排序校验（性能考虑），直接执行查找，结果完全取决于数据分布和具体实现细节。
- 可能返回
-1（碰巧没找到） - 可能返回一个看似合理的正索引（但指向错误元素）
- 可能返回形如
-(insertionPoint) - 1的负值，但该插入点毫无意义
如何快速定位是否误用
检查调用前是否有明确、可靠的排序动作，而非依赖“我以为它排好了”：
- 确认是否调用了
Collections.sort(list)或list.sort(Comparator)，且发生在binarySearch之前 - 注意并发修改：排序后若其他线程/代码修改了列表，排序状态即失效
- 留意构造方式：从数据库、文件或网络读取的数据通常未排序，不能直接查
安全使用的两个关键习惯
避免踩坑最有效的方式是把“排序”和“查找”绑定为原子操作逻辑：
立即学习“Java免费学习笔记（深入）”；
-
始终在 binarySearch 前加断言或日志（开发/测试环境）：
assert isSorted(list); // 自定义辅助方法 - 对频繁查找的场景，改用
TreeSet或TreeMap，它们自动维护有序性，contains()/get()时间复杂度也是 O(log n)
替代方案：不依赖排序的查找
如果数据天然无序，或排序开销过大，就别强用 binarySearch：
- 小列表（list.indexOf(obj)，代码清晰，性能差异可忽略
- 大列表需高频查找：先转成
HashSet（O(1) 查找），内存换时间 - 需要保持插入顺序 + 快速查找：考虑
LinkedHashSet或封装类维护双结构
