Go slices.BinarySearch 怎样判断输入是否满足边界

slices.BinarySearch 要求输入已经按升序排列；整数允许相等的相邻元素，因此更准确地说是非递减顺序。它不替你检查或排序输入。输入是否合格，可以在接收数据时用 slices.IsSorted 判断；返回位置是否能读取元素，则应结合 found 判断，不能只看位置非负。

设想一个按等级编号查询的整数列表：业务代码习惯“没找到就返回 -1”，换成标准库函数后却拿返回值直接索引。目标大于所有元素时，返回位置会等于切片长度，越界就出现在这里。本文用独立编写的整数索引示例，把输入归属和结果边界一起理清。

官方文档：https://pkg.go.dev/slices#BinarySearch

能力引入说明：https://go.dev/doc/go1.21

1. 能力变化一句话：标准库入口统一了，前提仍要保留

Go 1.21 将 slices 包引入标准库。针对整数或字符串这类有序类型，可以直接调用 BinarySearch，不再为同一任务手写一套整数查找函数。这里回顾的是已有能力，不是在宣称最新版本刚刚改变了二分查找语义；本文程序要求 Go 1.21 或以上版本。

使用上的简化，不代表有序前提被取消。编译器能约束元素类型，却不能从类型上证明一段运行时切片已经有序。输入合同仍然属于应用本身：要么拒绝无序数据，要么明确允许排序，并承担下标含义变化。

2. 为什么输入契约不能省

对本文的整数输入，升序检查意味着后一个元素不能小于前一个。重复值是合法输入，例如 12、18、18、27；12、27、18 则不满足前提。不要把“我查的这个值碰巧找到了”当作全体输入有序的证明，也不要从某次未命中推断目标真的不存在。

一次接收数据、随后查询多次的场景，适合在构建入口完成检查。若每次查询都先全量 IsSorted，整个查询入口就包含线性扫描，不能再把它的成本说成只有二分查找。这里不提供实测耗时，也不把少量示例作为吞吐量结论。

检查成功后仍须维护数据不变。其他代码若能通过共享底层数组改写元素，有序前提可能马上失效。复制输入、封装内部切片并不提供修改接口，是这个小例子的选择。复制期间调用方也不能并发修改输入；复制本身不解决数据竞争。

3. 对旧调用代码的影响：位置不是“命中下标或 -1”

BinarySearch 同时返回位置与是否命中。命中时位置对应第一个相等元素；未命中时位置表达排序顺序中的插入点。无序输入不属于它的有效使用前提，不应期待它返回一个专门的错误告诉你无序了。

如果目标只是“取第一个不小于目标的元素”，未命中也可能有候选，但仍必须检查位置小于长度。这与“查找等于目标的元素”是两项任务，不应共用一个含糊的 found 判断。

4. 迁移建议：把合法输入封装成有序索引

下面的示例选择拒绝无序输入，保留调用方给定的顺序。IntIndex 持有独立整数副本，NewIntIndex 建立输入合同，Lookup 返回插入位置与命中标志。没有提供原始切片的 getter 或修改方法。示例代码可保存为 main.go，本文未执行它。

package main

import (
    "fmt"
    "slices"
)

type IntIndex struct {
    values []int
}

func NewIntIndex(input []int) (*IntIndex, error) {
    // 先建立独立副本，构建成功后不向外暴露可修改切片。
    values := slices.Clone(input)
    if !slices.IsSorted(values) {
        return nil, fmt.Errorf("整数输入必须按非递减顺序排列")
    }
    return &IntIndex{values: values}, nil
}

func (idx *IntIndex) Lookup(target int) (int, bool, error) {
    if idx == nil {
        return 0, false, fmt.Errorf("索引未初始化")
    }
    // 数据归索引持有，查询不再重复线性检查有序性。
    pos, found := slices.BinarySearch(idx.values, target)
    return pos, found, nil
}

func main() {
    raw := []int{12, 18, 18, 27}
    idx, err := NewIntIndex(raw)
    if err != nil {
        fmt.Println(err)
        return
    }
    // 修改外部原切片不影响索引自己的整数副本。
    raw[0] = 99
    for _, target := range []int{10, 18, 23, 40} {
        pos, found, err := idx.Lookup(target)
        if err != nil {
            fmt.Println(err)
            return
        }
        if found {
            fmt.Printf("目标 %d 首次命中位置 %d\n", target, pos)
        } else {
            // 未命中的位置是插入位置，不能直接按此下标读取元素。
            fmt.Printf("目标 %d 未命中，可插入位置 %d\n", target, pos)
        }
    }
}

构建失败用 error 表达，未命中则是正常查询结果。Lookup 还单独处理 nil 接收者；有效的零值 IntIndex 持有空切片，可以作为空索引查询。main 中对原始 raw 的修改只用于说明副本归属，不会修改 idx 内部数据。

这是单包示例，values 虽未导出，同一包代码仍能访问它。实际项目应把索引放进独立包，并让修改规则成为包接口的一部分。如果支持插入、删除或批量替换，就必须继续维持有序性；有并发写入时还需要完整同步方案，不能只在检查函数外随手加一把短锁。

另一种产品选择是复制后排序，再构建索引。它适用于只关心集合查询、不要求原始位置的任务；不要静默地把排序当作“校验修复”。若结果要关联原始记录，应保留稳定标识或明确的映射。

5. 最小结果推导：先看空集与两端

以下均是根据固定输入和函数契约推导的预期值，不是实际运行日志。对列表 12、18、18、27：

空切片与 nil 切片都对应位置0、未命中；只有一个元素时，同样分别考虑目标小于、等于、大于该元素。不需要先访问首尾元素来判断能否调用 BinarySearch，那反而容易让空输入越界。

降序列表能直接查吗？

不能直接套用 BinarySearch 的升序合同。若选择自定义排序关系，需要用 BinarySearchFunc，并让比较规则与数据顺序一致；不能只改查找比较器却沿用另一种排序规则。

浮点数可以照搬整数示例吗？

本文刻意用整数限定问题。浮点数涉及 NaN 和应用自身的相等策略，不能把常规相邻大小检查直接泛化为所有数据的合同。需要浮点业务时应另行定义输入策略，避免用“差不多相等”的比较破坏排序关系。

调用后切片会自动插入目标吗？

不会，返回的是位置与标志。真正插入属于调用方的另一项修改操作，修改后还要确保有序关系和共享数据的访问规则成立。迁移时把这两项返回值命名清楚，比用一个通用 result 变量更容易保住边界。