Go的switch底层不自动转二分查找，仅对连续整数可能生成跳转表，否则为顺序比较；大量有序静态分支且性能瓶颈时，才需手动二分查找。
Go 的 switch 语句底层不是二分查找
Go 编译器对 switch 的优化策略取决于 case 数量、类型和值分布，**不会自动转成二分查找**。只有当 case 是连续或接近连续的整数（如 0, 1, 2, ..., 100），编译器才可能生成跳转表（jump table）；否则默认是顺序比较——哪怕有 50 个 case，也从上到下逐个判断 ==。
这意味着：写成 switch x { case 100: ... case 99: ... case 1: ... } 和按升序写，性能没区别；但如果你真想靠“排序+二分”提速，得手动实现，switch 不会帮你干这事。
什么时候该放弃 switch 改用二分查找
适用场景很明确：case 值是**大量、有序、静态、可预知的整数或字符串**，且查询频次高、分支多（比如 >20 个），同时你已确认 profile 显示 switch 成了瓶颈（别猜，用 go tool pprof 看）。
- 整数范围大但稀疏（如
case 1000, 2000, 5000, 9999）→ 用sort.SearchInts - 字符串枚举（如协议命令字
"GET","POST","PUT"… 共 30+ 个）→ 预先排序 +sort.SearchStrings - case 值来自配置或运行时加载 → 二分不适用，老实用 map 或 switch
注意：sort.Search* 要求切片已排序，且每次调用都有 O(log n) 开销——它省的是比较次数，不是内存或初始化成本。
立即学习“go语言免费学习笔记（深入）”；
sort.Search 手动二分的典型写法和坑
别直接套模板。核心是理解 sort.Search 的函数签名：func(n int, f func(int) bool) int，它找的是第一个让 f(i) == true 的索引。
常见错误：
- 传入未排序的切片 → 结果不可预测，
sort.Search不校验排序性 - 用
==判断相等后直接返回，却忘了sort.Search返回的是索引，不是值 - 字符串比较用了
strings.Compare但没处理/ <code>==0/>0分支，导致逻辑错位
正确示例（整数匹配）：
values := []int{10, 20, 30, 40, 50}
x := 30
i := sort.Search(len(values), func(j int) bool { return values[j] >= x })
if i < len(values) && values[i] == x {
// 找到了
}
map 查找比二分更快？看情况
对大多数实际场景（case 数 map[int]func() 的常数时间查找比二分更稳、更易读、更少出错。它的开销主要在哈希计算和一次内存寻址，而二分要多次数组访问 + 边界检查。
但要注意：
-
map有内存占用（即使空 map 也要约 200 字节），且 GC 压力略高 - 字符串 key 的 map 查找，哈希计算成本可能接近 3–4 次字符串比较，此时若 case 少于 10 个，
switch反而更轻 - 如果所有 case 值都是小整数（0–255），用切片索引（
table[x]）是最快方案，零分支、零哈希、零比较
真正需要较劲的地方，从来不是“该不该二分”，而是先确认 switch 是否真卡在那里——很多时候慢的是 case 里的业务逻辑，不是匹配本身。
