sort.search 不接受比较函数，只接收 func(int) bool 断言函数，需将查找逻辑转为“首个满足条件的位置”；正确用法是用 a[i] >= target 定位左边界，再验证值是否匹配，否则可能误将插入位置当找到。
sort.Search 为什么不能直接传比较函数
因为 sort.Search 设计上不接受比较函数，它只要一个 func(int) bool 断言函数——你得自己把“找某个值”翻译成“第一个满足某条件的位置”。很多人卡在这一步，以为它像 sort.SearchInts 那样封装好了值比较，其实不是。
常见错误现象：sort.Search(len(a), func(i int) bool { return a[i] == target }) —— 这会返回第一个 a[i] == target 的索引，但若目标不存在，它返回的是插入位置（即第一个 a[i] >= target 的位置），不是你想的“没找到就返回 -1”。
- 正确用法是把逻辑写成“
a[i] >= target”，然后额外判断结果位置是否越界或值是否真匹配 - 如果数组升序且含重复元素，
sort.Search找到的是最左边界，这点和sort.SearchInts一致 - 别在断言函数里做复杂计算或副作用，它会被调用多次，且顺序不保证
如何安全地用 sort.Search 查找等于 target 的元素
核心是两步：先定位左边界，再验证。不能省略验证，否则会把“插入点”误认为“找到了”。
使用场景：你在处理已排序切片，想快速判断某值是否存在，或获取其首次出现位置。
立即学习“go语言免费学习笔记（深入）”；
- 设
a = []int{1, 2, 2, 3, 5}，查target = 2：idx := sort.Search(len(a), func(i int) bool { return a[i] >= target }) if idx < len(a) && a[idx] == target { // 找到了，idx 是第一次出现的位置 } else { // 没找到 } - 查
target = 4时，idx会是4（因为a[4] == 5 >= 4），但a[4] != 4，所以进 else 分支 - 注意：这个模式只对升序有效；降序需改写断言为
a[i] ，且逻辑要反过来推
sort.Search 和 sort.SearchInts 性能差多少
几乎没差别。因为 sort.SearchInts 底层就是调用 sort.Search，只是帮你写了那层 func(i int) bool { return a[i] >= target }。
性能影响主要来自你的断言函数开销：如果里面做了内存分配、接口转换或调用了其他函数，就会拖慢二分过程。
- 避免在断言中访问 map、调用方法、或做字符串拼接
- 如果切片元素是结构体，且你要按某字段查，断言里直接取字段即可，别用闭包捕获大对象
- 编译器通常能内联简单断言，但一旦涉及接口类型（比如
interface{}切片），就会有类型断言开销，这时不如用sort.Search配合显式类型转换
容易被忽略的边界：空切片和越界访问
空切片传给 sort.Search 是合法的，它会直接返回 0；但如果你忘了检查 idx 就去读 <code>a[idx]，就会 panic。
另一个坑是：有人把 sort.Search 当作通用查找工具，用在未排序数据上——它不会报错，但结果完全不可预测。
- 空切片示例：
a := []int{}; idx := sort.Search(0, func(int) bool { return true }); // idx == 0 - 未排序数据下，断言函数返回值不满足单调性（即不是先 false 后 true），
sort.Search可能返回任意位置 - 如果目标值比所有元素都小，
idx为0；比所有都大，idx为len(a)—— 这两个都要单独判断，不能只看是否== len(a)
