SearchInts 查不到值时返回插入位置（0到len(arr)之间的整数），而非-1；需显式判断idx

SearchInts 查不到值时返回什么

sort.SearchInts 本质是 sort.Search 的封装，它不直接返回元素本身，而是返回「插入位置」——也就是如果目标值存在，就返回它最左边的索引；如果不存在，就返回它应该插入的位置（保持升序）。这跟 strings.Index 或 slice.Contains 的直觉不同，容易误判为“没找到就是 -1”。

常见错误现象：
写成 if idx := sort.SearchInts(arr, 42); idx != -1 { ... } —— 这永远成立，因为 SearchInts 永远返回 0 到 len(arr) 之间的整数，从不返回 -1。

• 正确做法：查完后必须显式判断 idx
• 如果只关心是否存在，别省那一次比较——二分查找省的是遍历开销，不是逻辑判断
• 注意：输入切片必须已排序，否则结果无意义；SearchInts 不校验，也不会 panic

SearchStrings 对中文或 Unicode 字符串安全吗

sort.SearchStrings 底层调用 strings.Compare，而后者按 UTF-8 字节序比较，对合法 UTF-8 字符串（包括中文）完全安全。但“安全”不等于“符合语义预期”——比如 “苹果” 和 “apple” 的字典序取决于编码字节，不是拼音或 Unicode 排序规则。

• 场景限制：仅适用于严格按 Go 字符串默认比较规则排序的切片（即 sort.Strings 排过的）
• 若切片用 golang.org/x/text/collate 或自定义规则排过序，SearchStrings 会失效
• 参数差异：SearchStrings 和 SearchInts 签名一致，但前者要求元素类型为 string，且不能传 []interface{} 混用
• 性能上无额外开销，和 SearchInts 一样是 O(log n)

自己用 sort.Search 实现泛型查找更灵活吗

Go 1.21+ 有泛型 sort.Slice，但 sort.Search 本身仍是 func(int) bool 形式，没泛型重载。所以想查 []float64、[]time.Time 或自定义结构体，必须手写 sort.Search 调用。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

立即学习“go语言免费学习笔记（深入）”；

• 关键点：回调函数里不能越界——i 可能等于 len(data)，此时访问 data[i] 会 panic
• 正确模板：

  idx := sort.Search(len(data), func(i int) bool {<br>    if i >= len(data) { return true }<br>    return data[i] >= target<br>})

• 容易踩的坑：用 > 替代 >= 会导致重复值时返回偏右位置，和 SearchInts 行为不一致
• 兼容性：该写法在所有 Go 版本都有效，比等效的 SearchInts 多两行，但换来类型自由

为什么 SearchInts 找不到时不能直接当“不存在”用

因为它的设计目标不是“查找存在性”，而是“定位插入点”。很多业务逻辑混淆了这两个意图：比如想删掉某个值，就先 SearchInts 找索引再 append(arr[:idx], arr[idx+1:]...)，但如果值不存在，idx 指向的是插入位置，删错元素。

• 典型错误：把 SearchInts 当作 FindIndex 用，却不验证值是否真等于目标
• 性能影响：多一次数组访问（arr[idx] == x）几乎无成本，但省掉它可能引发静默数据错误
• 边界 case：空切片 []int{} 调用 SearchInts 返回 0，此时 idx 为 false，自然跳过后续判断——这是唯一安全的空值处理方式

二分查找的插入语义是根深蒂固的设计选择，绕不开。真正容易被忽略的，是每次调用后那行不起眼的 arr[idx] == target —— 它不是可选优化，是语义必需。