sort.Search 的核心约束是必须传入单调函数，即 func(int) bool 在某个索引前全为 false、之后全为 true，用于定位边界而非查找存在性，返回满足条件的最小索引或 len(data)。
sort.Search 的核心约束：必须传入单调函数
它不接收目标值，也不直接操作切片，而是要求你提供一个 func(int) bool —— 这个函数在某个索引位置返回 true 之前，必须全部返回 false，之后全部返回 true。换句话说，它只适用于“前半段满足条件、后半段不满足”或反过来的严格单调分界场景。
常见误用是试图用它查某个具体元素是否存在：
sort.Search(len(a), func(i int) bool { return a[i] == x }) // ❌ 错！这不满足单调性
因为 a[i] == x 在数组中可能多次出现、中间穿插 false，无法保证分界唯一。
- 正确用途是找“第一个 ≥ x 的位置”：
func(i int) bool { return a[i] >= x } - 或“第一个 > x 的位置”：
func(i int) bool { return a[i] > x } - 甚至找插入点、左边界、右边界——但都依赖你把逻辑翻译成单调判定
为什么返回的是索引而不是 bool 或元素？
sort.Search 的设计意图不是“查存在”，而是“定位边界”。它返回的是满足 f(i) == true 的最小索引 i，如果全为 false 就返回 len(data)。
立即学习“go语言免费学习笔记（深入）”；
这意味着你得自己判断结果是否有效：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 若想找“是否存在 x”，得先用
sort.Search找到左边界l，再检查l - 若找“插入位置”，直接用返回值即可（比如
slice = append(slice[:i], append([]int{x}, slice[i:]...)...)） - 它不校验切片是否已排序——传入乱序数据会返回无意义索引，也不 panic
和 sort.SearchInts / SearchFloat64s 等封装函数的关系
这些是语法糖，内部就是调用 sort.Search + 预置判定函数。例如：
func SearchInts(a []int, x int) int {
return Search(len(a), func(i int) bool { return a[i] >= x })
}
它们省去了写匿名函数的麻烦，但代价是丧失灵活性：
-
SearchInts只能做 ≥ 比较；想查 > 或自定义逻辑（如忽略大小写字符串前缀匹配），必须回退到原生sort.Search - 所有封装函数都假设切片升序；降序时必须自己反转判定逻辑，比如用
a[i] 查“最后一个 ≤ x 的位置” - 没有泛型版本前（Go 1.18 之前），它们不支持自定义类型；现在虽有
sort.Slice配合sort.Search，但依然要手写判定
容易被忽略的边界行为：空切片与越界判定
当 len(a) == 0 时，sort.Search(0, f) 直接返回 0，不会 panic —— 这很安全，但容易让人忘记检查结果是否合法。
更隐蔽的问题是判定函数里的越界访问：
sort.Search(len(a), func(i int) bool { return a[i] >= x }) // ❌ 若 f 被调用时 i == len(a)，这里 panic
标准库实现保证 i 始终在 [0, n) 范围内，所以这个例子其实不会越界；但如果你在判定函数里做了额外计算（比如访问 a[i+1]），就可能崩。
- 永远不要在判定函数里假设
i+1 或 <code>i > 0 - 如果逻辑需要前后元素比较（如找峰值、找转折点），
sort.Search不适用，得手写二分或用其他策略 - 它的循环次数固定为 ⌈log₂(n)⌉，不因提前命中而退出——这不是 bug，是为保证最坏时间复杂度可控
