要使Collections.binarySearch高效，必须确保列表已升序排序且排序与查找逻辑一致；返回值为索引（≥0）或插入点（-return-1）；仅适用于支持随机访问的List，避免LinkedList、null未处理、并发修改及泛型错误。
要让 Collections.binarySearch 真正发挥高效检索作用，核心不是调用方法本身，而是严格满足它的运行前提——列表必须已按升序排列，且查找逻辑与排序逻辑完全一致。
确保列表已升序排序且排序方式与查找方式匹配
binarySearch 不做任何排序，也不校验顺序。传入乱序或降序列表，结果不可信。
- 对
String、Integer等自然有序类型，先调用Collections.sort(list) - 对自定义对象（如
Person），必须用同一Comparator排序和查找：
Collections.sort(people, byAge);
Collections.binarySearch(people, target, byAge); - 避免用
stream().sorted()后直接查——那是个新列表，原列表仍是乱的
正确理解并使用返回值
返回值不是布尔型，而是带位置语义的整数：
- ≥ 0：找到目标，数值即为索引
- < 0：未找到，插入位置 = -return value - 1（不是手算绝对值再减一）
- 例如返回
-4，说明应插入到索引3；返回-1表示应插在最前面（索引 0） - 插入位置始终在
[0, list.size()]范围内，可直接用于list.add(insertionPoint, e)
注意容器类型与数据安全边界
看似简单的方法，多数问题出在类型和环境细节上：
- 只支持
List，不支持Set或原始Collection - 数组需用
Arrays.asList(arr)包装，但arr必须是包装类型（Integer[]可以，int[]不行） - 列表含
null时，Comparator必须显式处理null，否则抛NullPointerException - 避免在
LinkedList上使用——它不支持高效随机访问，get(i)是O(n)，整个查找退化为慢操作
应对并发与泛型风险
多线程或泛型误用会悄无声息地破坏结果可靠性：
- 即使刚排完序，查找过程中若被其他线程修改列表，结果不保证正确
- 推荐将“排序 + 查找”封装为原子操作，或使用不可变列表（如 Guava 的
ImmutableList） - 禁止用原始类型（raw type）声明列表，例如
List list = new ArrayList()，混入不同类型的元素会导致运行时ClassCastException - 自定义类的
compareTo或Comparator必须满足自反性、传递性、一致性，且无副作用
