java中collections.binarysearch要求list必须已按指定comparator升序排序，否则结果不可信；需复用同一comparator实例，仅适用于支持randomaccess的list如arraylist，返回值≥0为索引，否则为插入点计算值。
Java 中 Collections.binarySearch 不是“拿来就能用”的查找工具，它严格依赖前置状态和比较逻辑的一致性。用错前提或 Comparator，结果看似运行无误，实则返回值完全不可信。
必须已排序且升序排列
binarySearch 不做任何排序校验，也不自动排序。它只假设你传入的 List 已按指定规则升序排好：
- 自然序类型（如
String、Integer）需先调用Collections.sort(list)，确保升序 - 降序排列的 List（哪怕只差一个元素位置）会导致索引错乱，返回负数也失去插入点意义
- 避免在每次查找前都
sort()—— 这样时间复杂度反超线性查找，得不偿失 - 推荐初始化时一次性排序；后续新增元素，用
binarySearch找到插入位置，再list.add(index, item)维持有序
Comparator 必须全程一致
自定义排序必须“从一而终”：排序用哪个 Comparator，查找就用哪个，且必须是同一个实例（不是“功能相同”的新对象）：
- 错误写法：
Collections.sort(list, Comparator.comparing(Person::getAge))，然后binarySearch(list, key, Comparator.comparing(Person::getAge))—— 两个 Lambda 是不同对象，比较行为可能不一致 - 正确做法：声明一个复用的 Comparator 变量，排序和查找都传它
- 若用
stream().sorted(comp).collect(Collectors.toList())，原 list 没变，新 list 虽有序，但容易混淆操作对象 - Comparator 内部应轻量：只比字段值，避免解析、IO、反射等耗时操作
List 类型要支持随机访问
binarySearch 内部频繁调用 get(i)，性能取决于 List 的随机访问效率：
-
ArrayList、Arrays.asList()返回的列表实现RandomAccess，能真正达到O(log n) -
LinkedList虽然能调用该方法，但每次get(i)是O(n)，整体退化为O(n)，不建议用于高频查找场景 - 如果增删远多于查找，可考虑
TreeSet或带排序视图的并发结构，而非硬套 binarySearch
返回值解读不能靠直觉
返回值是整数，不是布尔，必须按规则解码：
- ≥ 0：表示找到，值即元素在 List 中的索引
- -(插入点) - 1，例如返回
-3，说明应在索引2处插入（因为-(-3) - 1 = 2） - 不要用
result != -1判断是否存在 —— 若元素恰在索引 0 处，返回 0，但!= -1成立；若返回 -1，插入点是 0，不代表不存在 - 判断存在性请用
result >= 0
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
