Arrays.binarySearch仅在数组已排序、查找远多于增删、需精确索引且规模较大时最优；误用于未排序数组、频繁排序、仅判存在性等场景反而更慢。

Arrays.binarySearch 效率高，但只在数组已排序时才真正高效；用错场景反而比线性查找还慢。关键不是“能不能用”，而是“该不该用”。

什么时候该用 binarySearch

满足以下全部条件时，binarySearch 是最优解：

• 数据已是升序排列，或可低成本维持有序（如批量写入后统一排序）
• 查找操作远多于插入/删除（静态或准静态数据集）
• 需要精确位置索引，而非仅判断存在性
• 数组长度 ≥ 数千，性能敏感（小数组用 stream.anyMatch 更直观）

常见误用与性能陷阱

这些情况调用 binarySearch 不但没提速，还引入风险：

• 对未排序数组直接调用——结果不可预测，不报错但返回值无意义
• 每次查找前都 Arrays.sort() ——O(n log n) 排序开销远超 O(log n) 查找收益
• 用 Integer[] 混用 int[] 逻辑——Integer[] 走对象版，null 元素或 comparator 不兼容会抛 NPE
• 仅需判断“是否存在”，却用 binarySearch 再判返回值 ≥ 0——语义冗余，可直接用 contains 或 anyMatch

重复元素与边界定位的实际处理

binarySearch 不保证返回首个或末个匹配位置，但可通过简单扩展解决：

• 找第一个出现位置：调用 binarySearch 后，若命中，向左线性扫描直到值变化（适合重复少）
• 找左边界（推荐）：手写 leftBound 版本，循环条件用 left < right，右边界初始为 arr.length
• 找右边界：类似 leftBound，但条件改为 arr[mid] <= target，更新 left = mid + 1
• 自定义排序字段（如按字符串长度）：传入 Comparator.comparing(String::length)，无需改原始数据

替代方案对比：什么情况下换别的方法

不是所有“查找”都该走 binarySearch：

• 动态增删频繁 → 改用 TreeSet 或 TreeMap，自动维护有序且支持 O(log n) 增删查
• 数据量小（< 100）或查找极少 → 直接 for 循环或 Arrays.stream().anyMatch()，代码更清晰
• 需模糊匹配（前缀、范围、近似值）→ 二分本身可扩展，但建议封装 rank、lowerBound、upperBound 方法，而非硬套 binarySearch
• 非数组结构（如 List）→ 注意 Collections.binarySearch 可用于随机访问 List，但 LinkedList 不适用