Arrays.binarySearch 仅适用于已排序数组，时间复杂度O(log n)，手动遍历适用任意数组但为O(n)；小数组（≤1000）遍历更快，大数组（≥10000）binarySearch优势显著；频繁查找宜用HashSet或预排序+多次binarySearch。
Arrays.binarySearch 比手动遍历快，但只适用于已排序数组；手动遍历没有前提要求，但时间复杂度高。性能差距取决于数组大小和是否有序。
适用前提决定能否用 binarySearch
Arrays.binarySearch 要求数组必须升序排列（或按指定 Comparator 排好序），否则返回结果不可靠——可能找不到、找错位置，甚至返回负数却不代表不存在。而手动遍历（for 循环）对数组是否有序完全无感，任何情况都能用。
- 若数组原本无序，强行先调用 Arrays.sort() 再 binarySearch，总开销 ≈ O(n log n) + O(log n)，通常不如直接遍历 O(n)
- 若数组天然有序（如配置项列表、时间戳序列、预加载字典），binarySearch 才真正发挥优势
小数组 vs 大数组：性能拐点明显
实测数据表明：数组长度约 1000 是关键分界线。
- 长度 ≤ 1000：手动遍历往往更快（例如 1000 元素时，循环平均耗时约 2–3 万纳秒，binarySearch 约 5 万纳秒）
- 长度 ≥ 10000：binarySearch 稳定在 3–4 万纳秒量级，而遍历跃升至 90–440 万纳秒，差距达百倍
- 长度 100 万时，binarySearch 仍保持 ~3.5 万纳秒，遍历则需超 400 万纳秒
实际写法差异影响真实性能
不是“用了 binarySearch 就一定快”，还要看怎么用。
- 错误用法：对 String[] 直接 binarySearch 但未排序 → 结果无效，白费时间
- 低效用法：每次查找都 new HashSet(Arrays.asList(arr)) → 创建集合开销远超查找本身
- 推荐组合：一次排序 + 多次 binarySearch（适合反复查同一数组）；或维持插入时有序，避免重复排序
替代思路：根据场景选更合适的结构
如果频繁查找且数组内容变动少，数组本身未必是最佳载体。
- 查存在性（不关心位置）：HashSet.contains() 平均 O(1)，比 binarySearch 的 O(log n) 更快，且无需排序
- 查位置且需有序：用 TreeSet 或维护一个 SortedSet，支持 log 级插入+查找
- 查多个值：先把数组转为 Set 或 Map 建索引，后续查找都是常数时间
