Collections.binarySearch高效使用的前提是列表已按查找逻辑升序排序且支持随机访问：必须用ArrayList等支持O(1)访问的列表，排序与查找使用同一Comparator，返回值≥0为索引、<0时插入点=-result-1。
要让 Collections.binarySearch 真正高效定位数据，关键不在“调用它”，而在“让它能被安全调用”——它不排序、不校验、不兜底，只在你把前提全部做对之后，才返回一个精准索引或插入点。
必须确保列表已升序排序，且排序逻辑与查找逻辑完全一致
binarySearch 不检查顺序，也不帮你排序。传入降序、乱序或仅局部有序的列表，结果毫无意义。
- 对
String、Integer等天然实现Comparable的类型，先执行Collections.sort(list)即可 - 对自定义对象（如
Person），排序和查找必须使用同一个Comparator实例，不能只是“写法相似” - 避免用
list.stream().sorted().collect(Collectors.toList())—— 它生成新列表，原列表仍是乱的 - 推荐将比较器声明为
static final，例如：static final Comparator<string> CI_COMP = String.CASE_INSENSITIVE_ORDER;</string>
正确理解返回值：不是成功/失败，而是位置语义
返回值是整数，含义明确但易误读：
- ≥ 0：找到目标，数值即为该元素在列表中的真实索引
- < 0：未找到，但负数隐含插入位置 —— 插入点 = -result - 1
- 例如返回
-4，插入点是3；返回-1，插入点是0；返回-6（列表长度为 5），插入点是5（末尾之后） - 这个插入点始终落在
[0, list.size()]范围内，可直接用于list.add(insertIndex, key)维持有序性
容器类型和访问性能必须匹配
binarySearch 效率依赖随机访问能力，不是所有 List 都适用：
立即学习“Java免费学习笔记（深入）”；
- 只接受
List，不能传Collection、Set或数组本身 - 优先用
ArrayList；LinkedList表面能调用，但内部get(i)是 O(n)，整体退化为 O(n log n)，比线性遍历还慢 - 原始类型数组（如
int[]）不能直接用，需转为包装类型数组（如Integer[]），再用Arrays.asList()包装 - 列表含
null时，Comparator 必须显式支持（如Comparator.nullsFirst(Comparator.naturalOrder())），否则抛NullPointerException
注意并发与泛型安全边界
看似静态的方法，在多线程或类型不严谨场景下极易失效：
- 即使刚调完
sort()，查找过程中若被其他线程修改列表，结果不保证正确 - 推荐将“排序 + 查找”封装为原子操作，或改用不可变列表（如
ImmutableList） - 禁止使用原始类型声明（如
List list = new ArrayList()），混入不同类元素会导致运行时ClassCastException - 自定义
compareTo或Comparator必须满足自反性、传递性、一致性，且无副作用
