arrays.binarysearch要求数组必须升序排列，因其基于二分查找，依赖中点比较结果确定搜索方向；乱序时比较失去指导意义，导致结果不可靠；官方明确将其列为硬性契约，非可选优化。

因为 Arrays.binarySearch 是基于二分查找算法实现的，而该算法的逻辑成立前提就是数组必须升序排列。它不验证顺序，只“假设已排好”——传入乱序数组，就像给导航输入错误地图，算得再快，结果也大概率错。

核心原因：中点比较必须能指导方向

二分查找每一步都依赖“中间元素和目标值的大小关系”来决定搜左还是搜右。这个判断只有在数组升序时才有意义：

• 若 target ，说明目标只可能在左半段（前提是左半段所有元素 ≤ arr[mid]）；
• 若 target > arr[mid]，说明目标只可能在右半段（前提是右半段所有元素 ≥ arr[mid]）。

一旦数组乱序，arr[mid] 就无法代表“分界基准”，比较结果会误导搜索路径，导致跳过真实位置或陷入无效区间。

未排序时的典型错误表现

返回值看似有规律，实则无逻辑保障：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 查一个存在的元素，可能返回负数（伪失败）；
• 查一个不存在的元素，可能碰巧返回正索引（伪命中），但不可复现；
• 返回的负数本应表示插入点（如 -(insertIndex + 1)），但在未排序数组上，该值完全失去语义，不能用于插入定位。

排序不是“建议”，是方法契约的硬性要求

Java 官方文档和源码注释明确写有 “the array must be sorted”。这不是性能优化技巧，而是正确性底线：

• 用 Arrays.sort(int[]) 排序后，才能调 Arrays.binarySearch(int[], key)；
• 若用 Comparator 自定义排序，sort 和 binarySearch 必须使用同一个实例；
• 降序数组不能直接用，除非显式传入匹配的 Comparator（如 Collections.reverseOrder()）且确保排序时已按此规则执行。

常见误操作与规避方式

很多问题其实源于对“排序时机”和“数据状态”的忽视：

• 从文件、网络或用户输入拿到数组后，直接查，忘了排序；
• 排序后又修改了数组某个元素，破坏了有序性；
• 误以为“几乎有序”或“只有一个逆序对”影响不大——只要存在一处违反单调性，就可能让算法走偏；
• 混淆类型：对 List 用了 Collections.sort()，却拿原数组去调 Arrays.binarySearch()（类型不匹配，逻辑断层）。

稳妥做法：不确定是否有序，就先 Arrays.sort()；需要保留原数组，就先复制再排序。