直接对未排序list调用collections.binarysearch返回值不可信，因其依赖有序性划分区间，乱序导致逻辑错误；comparator不一致、linkedlist不适用、负数返回值仅在有序时表插入位置。
直接对未排序的 List 调用 Collections.binarySearch 不会报错，但返回值完全不可信——它不是“慢”，而是“错”。根本原因在于：二分查找依赖有序结构划分搜索区间，乱序数据会让中间元素失去划分能力，整个算法逻辑崩塌。
未排序时返回值为何看似“随机”？
binarySearch 不验证顺序，只机械执行二分流程。例如列表 [5, 1, 8, 3] 查找 3：
- 第一次取索引 1 的元素
1，判断3 > 1，于是放弃左半段（含真实位置 3），只搜右半段[8, 3]； - 后续比较在错误子区间进行，最终可能返回负数（如
-4），但这并非有效插入点； - 偶尔返回正数（如
2），查出来却是8，属于伪命中，不可复现。
Comparator 不一致等于白排序
排序和查找必须使用**同一个 Comparator 实例**，哪怕语义相同也不行：
- 用
Comparator.comparing(String::length)排序，却用Comparator.comparing(String::toLowerCase)查找 → 比较逻辑错位，结果失效； - Lambda 表达式每次调用生成新对象，两次写法相同也会引用不同 → 建议声明为
static final字段复用； - 升序排完，用
comparator.reversed()查找 → 等同于在逆序数据上硬套升序二分，必然出错。
别拿 LinkedList 当二分容器
Collections.binarySearch 内部频繁调用 get(int) 获取中点，而 LinkedList 的 get 是 O(n) 遍历：
- 对长度为 n 的 LinkedList 执行 binarySearch，时间复杂度退化为 O(n log n)，比线性扫描还慢；
- 只适用于
ArrayList、Vector等支持随机访问的 List 实现； - 若数据结构本身是链式，应改用
TreeSet或TreeMap，它们天然有序且提供 O(log n) 查找。
负数返回值不是“没找到”，而是“插入线索”
返回 -x 并非简单表示不存在，而是编码了精确插入位置：
- 公式：
insertionIndex = -returnVal - 1； - 返回
-4→ 应插入索引3；返回-1→ 应插入索引0； - 该信息仅在列表**确实有序**时有效，未排序时负数无实际意义。
