binarysearch要求list必须已排序且比较逻辑一致，否则结果不可信；未排序、comparator不匹配、非randomaccess实现（如linkedlist）或误读负数返回值均会导致错误。
binarySearch 要求 List 必须已排序，否则结果不可信
这是最常踩的坑：直接对 ArrayList 调用 Collections.binarySearch，却没确认它是否有序。函数本身不校验顺序，只按二分逻辑读取中间元素——如果数据乱序，返回值可能是任意负数（表示插入点），也可能是错误的正索引。
常见错误现象：Collections.binarySearch(list, target) 返回 -1，但你知道 target 确实在列表里；或者返回某个正数索引，但查出来发现是错的元素。
- 使用场景：适合一次性排序、多次查找的场景，比如配置项白名单、枚举映射表、静态字典
- 排序必须用和查找时相同的比较逻辑：如果用
String.CASE_INSENSITIVE_ORDER排序，查找时也得传同一个Comparator - 别依赖
list.sort()后立刻查——要确保排序完成且未被后续修改
传 Comparator 时必须和排序时完全一致
哪怕只是多一个 nullsFirst() 或少一个 reversed()，binarySearch 就会失效。Java 不做兼容性推断，它只机械地执行二分过程，前提是“数组在该 comparator 下单调”。
示例：你用 Comparator.comparing(String::length) 排了序，但查找时传了 Comparator.naturalOrder()，结果必然错。
立即学习“Java免费学习笔记（深入）”；
- 参数差异：不传
Comparator表示用元素自身的Comparable实现；传了就必须和排序所用实例完全相同（引用相等或语义等价） - 容易忽略：Lambda 写法每次都会生成新对象，所以排序和查找都用
Comparator.comparing(String::toLowerCase)是错的——两次调用产生两个不同实例 - 稳妥做法：定义为
static final Comparator字段复用
高频查找下，List 需是 RandomAccess 实现
binarySearch 内部会反复通过 get(int) 访问中间位置。如果传入的是 LinkedList，每次 get 都是 O(n)，整个查找退化成 O(n log n)，比线性扫描还慢。
性能影响明显：10 万元素的 LinkedList 上二分，可能比 ArrayList 上线性扫描慢 10 倍以上。
- 检查方式：用
list instanceof RandomAccess判断，不是就别硬上binarySearch - 替代方案：真要用链式结构+高频查找，考虑先转成
ArrayList，或换TreeSet/TreeMap - 注意：
Arrays.asList()返回的 list 是RandomAccess，但底层是数组，没问题
返回值不是布尔值，负数含义要手动解析
很多人误以为返回 -1 就代表“没找到”，其实负数表示“应插入的位置”，计算公式是 -(insertionPoint) - 1。直接拿 result 当“不存在”是对的，但若想取插入点，得自己解包。
错误用法：if (index == -1) { /* not found */ } ——漏掉了 -2、-3 等所有其他负值。
- 正确判断存在性：只用
index >= 0 - 需要插入逻辑时：用
-(index + 1)得到插入下标 - 别和
Arrays.binarySearch混淆：后者行为一致，但类型更明确；而Collections.binarySearch对List的约束更隐晦
实际用的时候，最容易被绕进去的是“我以为排过序了”，结果中间有并发写入、或排序用的 comparator 和查找不一致、或根本没排序——这些都不会报错，只会静默返回错误结果。
