要让Collections.binarySearch高效，须确保列表已升序、类型一致、支持RandomAccess；返回值≥0为索引，负数时插入点=-result-1；需规避null、并发、泛型擦除等陷阱。
要让 Collections.binarySearch 真正实现高效集合搜索，关键不在“调用它”，而在于让它运行在一条被严格保障的路径上：列表已升序、类型一致、访问高效、逻辑统一。
必须提前排序，且排序与查找用同一规则
binarySearch 不排序、不校验、不修复顺序。传入未排序或逻辑错位的列表，结果完全不可信。
- 对
String、Integer等天然有序类型，先执行Collections.sort(list) - 对自定义对象（如
Person），排序和查找必须复用同一个Comparator实例——不是“写法类似”，而是内存中同一个对象 - 避免
list.stream().sorted().collect(Collectors.toList())：它返回新列表，原列表仍是乱序 - 浮点数、忽略大小写的字符串等场景，需警惕精度或比较规则偏差导致“看似有序实则错位”
返回值是位置语义，不是布尔开关
它返回的整数自带坐标信息，理解这点才能解锁真实能力。
- ≥ 0：找到目标，数值即为索引，可直接
list.get(result) - 负数：未找到，插入点 = -result - 1（不是取绝对值再减一）
- 例如返回
-4，插入点是索引3；返回-1，应插在开头（索引0） - 该插入点始终落在
[0, list.size()]范围内，可直接用于list.add(insertionPoint, key)
只认 RandomAccess 列表，避开性能陷阱
二分查找依赖 O(1) 随机访问。不满足这点，算法会退化，甚至比线性扫描还慢。
- 优先使用
ArrayList或Arrays.asList()包装的固定列表 - 禁用
LinkedList：它的get(i)是O(n)，整体查找退化为O(n log n) - 数组需用
Arrays.asList(new Integer[]{...})包装；int[]不支持，必须是包装类型数组 - 运行时可用
list instanceof RandomAccess做轻量判断，不满足就换结构或改用TreeSet
边界情况必须显式兜底
看似简单的方法，崩溃常发生在 null、并发、泛型擦除等“安静”的角落。
- 列表含
null元素时，Comparator必须显式处理（如Comparator.nullsFirst()），否则抛NullPointerException - 多线程环境下，排序后、查找前若被其他线程修改列表，结果不保证可靠；推荐封装为原子操作，或使用不可变列表（如 Guava 的
ImmutableList） - 禁止原始泛型声明（如
List list = new ArrayList()），混入不同类型会导致运行时ClassCastException - 别对
Set、Map或裸数组调用——它只接受List，且要求支持随机访问
