Collections.binarySearch是严格依赖升序前提的轻量级二分定位工具，返回索引或插入点，要求排序与查找使用同一Comparator，仅适用于RandomAccess列表。
直接说结论：Collections.binarySearch 不是“高级检索”，它就是一个严格依赖前提的、轻量级的二分定位工具——用对了很高效，用错了毫无意义。它的价值不在功能丰富，而在精准和确定性。
必须先排序，且只认升序
binarySearch 从不排序，也不检查顺序。它假设你传入的 List 已经按自然序（或指定 Comparator）严格升序排列。哪怕只有一个元素位置错乱，结果就不可靠。
- 基本类型或 String/Integer 等：调用 Collections.sort(list) 即可
- 自定义对象（如 Person）：必须用同一 Comparator 先排序，再用同一个 Comparator 查找
- 别用 stream().sorted().collect() ——那生成的是新 List，原 list 还是乱的
- 降序排列的列表不能直接用；如需降序查找，要么反转逻辑（用负向 Comparator），要么转为升序处理
返回值不是“是否找到”，而是位置语义
返回值携带明确的位置信息，不是布尔判断：
- ≥ 0：表示找到了，数值就是该元素在 List 中的索引
- 负数：表示没找到，但告诉你“如果要插入并维持有序，该放哪儿”——计算方式是 -result - 1
- 例如返回 -4，插入点就是索引 3；返回 -1，说明应插在开头（索引 0）；返回 -(size+1)，说明应插在末尾（索引 size）
- 这个插入点可直接用于 list.add(-result - 1, target)，适合构建动态有序缓存
Comparator 必须完全一致
排序和查找用的 Comparator 必须是同一个实例，或至少逻辑完全等价。哪怕只是字符串长度 vs 字符串字典序，或正序 vs 逆序，都会导致结果错误。
- 升序排完，却用降序 Comparator 去查 → 相当于在乱序数据上硬套二分，结果无意义
- Comparator 中若涉及 null，必须显式处理（如 Comparator.nullsFirst()），否则运行时抛 NullPointerException
- 对 LocalDate、BigDecimal 等类型，注意比较器是否考虑时区、精度等细节
只适合 RandomAccess 列表
binarySearch 内部依赖随机访问（O(1) 取任意索引元素），因此只适合 ArrayList、Arrays.asList 包装的数组等实现 RandomAccess 接口的 List。
- 千万别在 LinkedList 上用——get(i) 是 O(n)，整个查找退化为 O(n log n)，比线性扫描还慢
- 可用 list instanceof RandomAccess 提前校验
- 如果数据结构本身是链式或频繁变更，优先考虑 TreeSet / TreeMap，它们天然支持有序查找与动态维护
- int[] 不能直接用，需转为 Integer[] 或用 Arrays.stream(arr).boxed().collect(...) 构建 List
