sort.Search不是通用搜索函数，而是二分查找满足条件的第一个索引；需传入升序切片和返回bool的闭包，参数为索引而非元素值，结果需手动验证是否等于目标。
Go 标准库没有 Search 函数，别被名字带偏
Go 语言标准库中并不存在名为 Search 的独立函数。你可能在文档或旧代码里看到类似写法，实际是误传或混淆了 sort.Search —— 它不是“搜索某值”，而是“在已排序切片中查找满足条件的第一个位置”。它不接受目标值，只接受一个闭包函数，返回布尔结果。
常见错误现象：undefined: Search 或调用后逻辑错乱，比如总返回 0、越界 panic，或看似找到了却不是目标索引。
-
sort.Search要求输入切片必须升序（或按你闭包定义的单调性有序），否则行为未定义 - 它返回的是插入点（即第一个使条件为
true的索引），不是“是否找到”的布尔值，需手动比对 - 闭包参数是
int（索引），不是元素值；写成func(i int) bool { return slice[i] == target }才对，别漏掉slice[i]
用 sort.Search 实现二分查找目标值的正确姿势
想查某个具体值是否存在并返回其索引？必须自己封装一层：先调用 sort.Search 得到候选索引，再判断该位置是否真等于目标值。
示例（升序 []int 中找 target）：
立即学习“go语言免费学习笔记（深入）”；
idx := sort.Search(len(slice), func(i int) bool {
return slice[i] >= target // 注意：>=，不是 ==
})
if idx < len(slice) && slice[idx] == target {
// 找到了，idx 是第一次出现的位置
} else {
// 没找到
}
关键点：
- 闭包中用
>=（不是==），才能让sort.Search定位到“首个 ≥ target”的位置 - 必须检查
idx < len(slice)，否则越界 panic（比如 target 大于所有元素时返回len(slice)） - 即使
idx合法，也必须显式比较slice[idx] == target，因为sort.Search不保证相等
为什么不用 sort.SearchInts 等快捷函数？
Go 提供了 sort.SearchInts、sort.SearchStrings 等预置函数，看起来更省事。但它们只是 sort.Search 的封装，内部逻辑完全一样：返回插入点，不自动校验相等性。
例如：sort.SearchInts([]int{1,3,5}, 4) 返回 2（因为 5 >= 4），但 slice[2] 是 5，不等于 4 —— 它不负责告诉你“没找到”，你仍要自己判断。
- 这些快捷函数只省了闭包写法，没省逻辑判断，该写的边界检查和相等校验一个都不能少
- 它们仅支持基本类型（
int、string、float64），自定义结构体或复杂比较规则时，必须回到sort.Search+ 自定义闭包 - 性能上无差异，底层都是同一套二分逻辑
非排序数据别硬套二分，for 遍历有时更合理
二分查找的前提是“有序”。如果你的数据没排过序，强行先调 sort.Sort 再二分，时间复杂度从 O(n) 变成 O(n log n)，反而比直接 for 遍历慢，尤其数据量小或只查一次时。
适用场景判断：
- 单次查询 + 切片小（for，代码短、分支少、CPU cache 友好
- 多次查询 + 数据固定 → 排序一次，之后全用
sort.Search* - 动态增删 + 频繁查询 → 考虑用
map或map[int]struct{}做 O(1) 查找，而非维护有序切片
容易忽略的一点：二分的“快”是建立在预处理（排序）或数据天然有序的前提下。没这个前提，它就不是银弹。
