Collections.binarySearch仅在列表升序、比较逻辑一致且支持随机访问时稳定达O(log n)；返回值含位置语义：≥0为索引，<0时插入点=-结果-1；须用ArrayList，禁用LinkedList；排序须提前完成且不可省略。
Collections.binarySearch 不是“拿来就能快”的黑盒，而是把高效交给准备的人——它只在列表已升序排好、比较逻辑完全一致、容器支持随机访问的前提下，才稳定给出 O(log n) 的查找结果。用错一次，就可能查到错误位置或误判存在性。
排序必须提前做，且只能是升序
binarySearch 从不排序，也不校验顺序。传入降序、乱序或仅局部有序的 List，结果不可信。
- 对 String、Integer 等天然可比类型，调用 Collections.sort(list) 即可完成升序准备
- 对自定义对象（如 Person），排序和查找必须使用同一个 Comparator 实例，不能只是“写法相似”
- 避免用 list.stream().sorted().collect(Collectors.toList()) ——它返回新 List，原 list 仍是乱的
- 推荐将 Comparator 定义为 static final，例如：static final Comparator<String> CI_COMP = String.CASE_INSENSITIVE_ORDER;
返回值不是布尔信号，而是位置语义整数
理解返回值才能真正用好它：它既告诉你“在哪”，也告诉你“该插哪”。
- ≥ 0：找到目标，数值就是其在 List 中的真实索引（从 0 开始）
- < 0：未找到，插入点 = -result - 1（不是手算绝对值再减一）
- 例如返回 -4 → 插入点是 3；返回 -1 → 插入点是 0；返回 -6（列表长度为 5）→ 插入点是 5（末尾后）
- 该插入点始终落在 [0, list.size()] 范围内，可直接用于 list.add(insertIndex, key)
容器类型决定性能上限，选错等于白忙
binarySearch 的 O(log n) 效率，依赖底层能 O(1) 随机访问。不是所有 List 都达标。
立即学习“Java免费学习笔记（深入）”；
- 优先用 ArrayList：支持高效随机访问，是 binarySearch 的理想搭档
- 别用 LinkedList：其 get(i) 是 O(n)，整体查找退化为 O(n log n)，比遍历还慢
- 数组需包装：用 Arrays.asList(arr)，但 arr 必须是包装类型（Integer[] 可以，int[] 不行）
- 含 null 时，Comparator 必须显式处理，例如用 Comparator.nullsFirst(…)，否则抛 NullPointerException
高频查找场景下的实用守则
它最适合“一次排序、多次查找”的静态或低频变更数据，而非边改边查的动态集合。
- 避免每次查找前都 sort()：那样总成本是 O(n log n)，不如线性查找
- 并发环境下，即使刚排完序，查找过程中若被其他线程修改列表，结果不保证正确
- 推荐封装“排序 + 查找”为原子操作，或使用不可变列表（如 Guava 的 ImmutableList）
- 泛型声明禁止裸写 List list，必须带类型参数，防止混入异构元素导致 ClassCastException
