同样是 5 个分支的 C 语言 switch 语句，当分支值间隔为 7（0、7、14、21、34）时，GCC 在 -O3 优化下会干脆地生成一张 O(1) 跳转表；一旦间隔拉大到 8（0、8、16、24、40），跳转表瞬间消失，退化成一棵 O(log N) 的二分比较决策树。技术博主 Xoranth 近期更新的一篇汇编实测笔记（初稿写于 2024 年 1 月 14 日，网页更新于 2025 年 1 月 5 日）把这个反常切面摆上了台面，尽管他并未注明实测所用的具体 GCC 版本号。许多底层程序员习惯把 switch 当成天然的高速查表语法，但 GCC 与 Clang 的源码账本表明，编译器内部有一套严苛的聚类优先级与密度公式，盲目堆砌分支往往得不到预期的机器码。
间隔 7 与 8 的分水岭，藏在 800% 的比较密度公式里
Xoranth 在测试中发现，GCC 不仅能把紧凑分支转为跳转表，还会用一条 lea eax, [rdi-97] 指令顺手抹平 97 到 101 这类常数偏移。遇到 1 到 5 搭配一个离群值 100 的情况，编译器也能把 100 单独剥离成条件跳转，保留前 5 个值的紧凑跳转表。
真正决定跳转表生死的，并不是许多开发者凭直觉猜测的“每个 case 最多容忍几个空位”。翻开 GCC 源码 tree-switch-conversion.cc 中的 jump_table_cluster::can_be_handled() 函数，核心判定公式其实是 100 range <= max_ratio comparison_count。这里的基准是比较次数而非分支个数：单个离散值算 1 次比较，而像 case 42 ... 45 这样指向同一函数的连续范围，无论跨度多长，编译器只需验证上下界，一律只记 2 次比较。
在 GCC 的 params.opt 配置文件里，面向速度优化的 jump-table-max-growth-ratio-for-speed 默认值是 800（即跨度不超过比较次数的 8 倍），面向体积优化的 jump-table-max-growth-ratio-for-size 默认值则是 300（即 3 倍）。Xoranth 在博文中修正了比较次数的概念，却把体积优化的比例误写成了 2 倍。此外，跳转表要想真正落地，还必须跨过 jump_table_cluster::is_beneficial() 的最小聚类门槛，该阈值受 --param case-values-threshold=N 控制，设为 0 时则直接调用目标硬件架构的默认配置。
这套算术逻辑直接解释了为什么 20 个连续范围凑在一起（如 0 到 3、21 到 24 等共 5 组，总跨度 88）反而生不出跳转表：5 组连续范围只折算成 10 次比较，乘以 8 倍上限也才 80，压不住 88 的跨度，编译器自然果断放弃填表。
位测试半路截胡，Clang 并没有缺席这场优化
当多个不连续的分支指向同一个代码块时，汇编里甚至连比较指令和跳转表都见不到。比如匹配 '0'、'2'、'A' 等 9 个零散字符时，GCC 生成了一个魔数 2753205 和一条 x86 的 bt（位测试）指令。它把字符偏移压进一个 64 位寄存器整数里，靠硬件一次核验对应比特位是否为 1。
在 GCC 的 analyze_switch_statement 流程里，位测试优先级高于跳转表。编译器会先跑一遍动态规划函数 bit_test_cluster::find_bit_tests，把能打包的分支提前截胡，剩下的残余简单分支才有机会去申请建跳转表，最后兜底的才是二分决策树。只要分支总跨度落在机器字长（word_mode，64 位系统即 64）以内，且跳往的不同目标代码块不超过 3 个，一旦 1、2、3 个目标块对应的简单聚类数分别达到 3、5、6 个，位测试就会直接接管。
需要纠偏的是，Xoranth 在导言中断言“除位测试外，所有优化都适用于 Clang”，这与事实不符。查阅 LLVM 源码库中的 SwitchLoweringUtils.cpp 即可确认，Clang 同样原生支持位测试，且遵循“单机器字宽内最多 3 个不同目标基本块”的同类启发式规则。两大主流编译器在压榨寄存器位运算这件事上早就殊途同归。
为什么不除以 8，以及工程师该如何接管方向盘
面对 case 0, 8, 16, 24, 40 退化成比较树的现象，原博文提出了一个看似聪明的疑问：为什么编译器不把输入值先除以 8（右移 3 位），压缩成 0 到 5 的紧凑跳转表？
答案藏在余数校验的隐性成本里。如果输入是 9 或 10，右移 3 位后同样等于 1，会误触发 case 8 的逻辑。编译器若想做这类代数因式分解，必须在查表前额外插入检查低 3 位是否为 0 的指令与分支；一增一减之间，指令周期和分支预测器负担未必划算，通用编译器因此普遍放弃这种投机简化。
静态汇编里漂亮的跳转表，放到真实流水线上未必是赢家。
这也是唯汇编论最容易踩坑的地方。跳转表依赖间接跳转指令（如 jmp [rax*8]），在现代处理器上容易遭遇分支目标缓冲器（BTB）冲突，在开启幽灵漏洞防护（如 retpoline）的内核环境里更是性能重灾区。反观二分比较树，全是条件直接跳转；如果线上真实流量高度集中在某一两个热分支上，CPU 分支预测器几乎能做到零开销猜中，跑起来往往比跳转表更快。此外，若所有分支只是返回不同常量，GCC 默认还会直接将其优化为标量结果查找数组（可用 -fno-tree-switch-conversion 关闭）。
编写字节码虚拟机解释器、网络协议解析器的高性能 C/C++ 开发者，以及对 Flash 容量锱铢必较的嵌入式固件工程师，与其为了凑齐 8 倍密度去手动改枚举值，不如直接用编译器留好的开关接管策略：
- 建议.在 ROM 极其受限的嵌入式固件中，若不想一刀切用
-fno-jump-tables彻底禁掉跳转表，可通过调低--param jump-table-max-growth-ratio-for-size严控空白表项膨胀；而在高性能服务端，开启 PGO（反馈导向优化）把真实流量概率喂给analyze_switch_statement，比手写函数指针数组更稳妥。 - 风险.做微基准测试时切忌用顺序递增的循环喂给
switch，那会让 CPU 分支预测器跑出虚假满分，掩盖间接跳转在线上随机流量下的真实延迟回退；排查特定指令退化时，可配合-fno-bit-tests隔离验证位测试的实际收益。