Arrays.binarySearch要求数组必须升序排列，因其基于二分查找，依赖中点比较结果确定搜索方向；乱序时比较失去指导意义，导致结果不可靠；官方明确将其列为硬性契约，非可选优化。
因为 Arrays.binarySearch 是基于二分查找算法实现的，而该算法的逻辑成立前提就是数组必须升序排列。它不验证顺序，只“假设已排好”——传入乱序数组，就像给导航输入错误地图，算得再快，结果也大概率错。
核心原因：中点比较必须能指导方向
二分查找每一步都依赖“中间元素和目标值的大小关系”来决定搜左还是搜右。这个判断只有在数组升序时才有意义：
- 若
target < arr[mid]，说明目标只可能在左半段（前提是左半段所有元素 ≤ arr[mid]）； - 若
target > arr[mid]，说明目标只可能在右半段（前提是右半段所有元素 ≥ arr[mid]）。
一旦数组乱序，arr[mid] 就无法代表“分界基准”，比较结果会误导搜索路径，导致跳过真实位置或陷入无效区间。
未排序时的典型错误表现
返回值看似有规律，实则无逻辑保障：
- 查一个存在的元素，可能返回负数（伪失败）；
- 查一个不存在的元素，可能碰巧返回正索引（伪命中），但不可复现；
- 返回的负数本应表示插入点（如
-(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()；需要保留原数组，就先复制再排序。
