binarySearch要求List必须是RandomAccess类型且已排序，否则退化为线性查找或返回错误结果；返回值正数为索引，负数表示插入位置；需确保排序与查找使用同一比较逻辑，避免null导致NPE。
binarySearch 要求 List 必须是 RandomAccess 类型
直接对 LinkedList 调用 Collections.binarySearch() 虽然能编译通过，但实际退化为线性查找——因为 binarySearch 内部会反复调用 get(i)，而 LinkedList.get(i) 是 O(n) 的。只有实现 RandomAccess 接口的集合（如 ArrayList、Arrays.asList() 返回的列表）才能真正获得 O(log n) 性能。
实操建议：
- 确认你的
List是ArrayList或包装自数组（Arrays.asList(arr)），否则换用TreeSet或手写二分更稳妥 - 若数据来自数据库或流式构造，优先用
ArrayList收集，别用LinkedList图省事 - 可通过
list instanceof RandomAccess运行时校验
必须保证 List 已按自然序或指定 Comparator 排序
Collections.binarySearch() 不检查顺序，只假设已排序。如果传入乱序列表，返回值完全不可预测——可能返回负数（看似“未找到”），也可能碰巧返回正索引（指向错误位置）。
常见错误现象：
- 测试时小数据偶尔“碰对”，上线后数据量增大或顺序微变就出错
- 用
Comparator排序后，调用 binarySearch 时却没传相同 comparator，结果错位
实操建议：
- 排序和查找必须使用同一套比较逻辑：要么都用自然序（元素实现
Comparable），要么都显式传入同一个Comparator实例 - 生产环境建议加断言：
assert isSorted(list, comparator);（自行实现简单校验） - 避免在多线程中边修改边查找；排序和查找之间不能有并发写入
理解返回值含义：正数是索引，负数需取反再减 1
返回值不是简单的“找到/未找到”，而是带位置信息的编码值。例如返回 -5，不代表“第 5 个位置没找到”，而是表示“应插入位置为 4”（因为 -(4 + 1) == -5）。
实操建议：
- 判断是否找到：用
result >= 0，不是result != -1 - 获取插入点：用
-(result + 1)，不是~result（虽然位运算等价，但可读性差且易错） - 若只需判断存在性，别忽略负数返回值直接取
list.get(result)，那会抛IndexOutOfBoundsException
对比 Arrays.binarySearch()：List 版本有额外开销
对 ArrayList，Collections.binarySearch(list, key) 和 Arrays.binarySearch(list.toArray(), key) 都是 O(log n)，但前者多了每次 get(i) 的边界检查和泛型类型擦除开销；后者需额外数组拷贝（O(n) 时间 + O(n) 空间）。
性能权衡点：
- 单次查找：优先用
Collections.binarySearch()，避免拷贝 - 高频查找同一数组数据：先转成
int[]/String[]等原始/引用数组，再用Arrays.binarySearch()，绕过泛型和 List 封装 - 若 List 是
Arrays.asList(new Integer[]{...})包装的，底层仍是数组，Collections.binarySearch()效率接近原生数组版
最容易被忽略的是：binarySearch 对 null 值极其敏感。如果 List 允许 null，而 comparator 没处理 null（比如用了 Comparator.naturalOrder()），运行时直接抛 NullPointerException。哪怕只在一个元素上出现 null，整个查找就崩。
