要让collections.binarysearch高效，关键在于确保列表已严格升序排序且排序与查找逻辑一致；必须用同一comparator、避免stream.sorted()生成新列表；返回值≥0为索引，＜0时插入点为-result-1；仅支持arraylist等随机访问list，禁用原始泛型。
要让 Collections.binarySearch 真正高效，关键不是调用它，而是让它“有路可走”——这条路就是一条严格有序、类型一致、访问可控的路径。
列表必须已升序排序，且排序与查找逻辑完全一致
binarySearch 不排序、不校验、不修复。它只认“已排好”的事实。
- 对
String、Integer等天然有序类型，先执行Collections.sort(list) - 对自定义对象（如
Person），排序和查找必须复用同一个Comparator实例，不能只是“写法相似” - 避免用
stream().sorted()后直接查——那生成的是新列表，原列表仍是乱的 - 浮点数、忽略大小写的字符串等场景，要警惕精度或比较规则偏差导致的“看似有序实则错位”
返回值不是成功/失败信号，而是位置语义编码
它返回的整数自带坐标信息，理解它才能真正用起来。
- ≥ 0：找到，数值就是索引，可直接
list.get(result) - ＜ 0：未找到，插入位置 = -result - 1（不是绝对值减一，也不是手算）
- 例如返回
-4，插入点是索引3；返回-1，应插在开头（索引0） - 这个插入点始终落在
[0, list.size()]范围内，可直接传给list.add(insertionPoint, e)
容器类型和数据边界必须匹配
不是所有“看起来像列表”的结构都适合 binarySearch。
- 只支持
List，不接受Set、Collection或数组本身 - 优先用
ArrayList；LinkedList表面能调用，但get(i)是O(n)，整体退化为慢查找 - 数组需用
Arrays.asList(arr)包装，但arr必须是包装类型（Integer[]可以，int[]不行） - 列表含
null时，Comparator必须显式处理（如Comparator.nullsFirst()），否则抛NullPointerException
高频查找场景下的稳定前提保障
binarySearch 的高效，依赖于“一次准备、多次使用”的静态前提。
- 适合数据初始化后排序、后续只读或低频变更的场景
- 并发环境下，即使刚排完序，查找中若被其他线程修改列表，结果不可靠
- 推荐将“排序 + 查找”封装为原子操作，或使用不可变列表（如 Guava 的
ImmutableList） - 泛型声明必须规范，禁用原始类型（如
List list），防止混入不同类型引发运行时异常
