Switch有时比if-else快，是因为编译器在满足密集整数case、值域合理、全为编译期常量等条件时生成O(1)跳转表；否则退化为二分查找或链式if-else，性能更差。
Switch 为什么有时比 if-else 快？关键看是否生成跳转表
编译器对 switch 的优化不是自动发生的，它只在满足特定条件时才生成跳转表（jump table）——一种 O(1) 查表分支结构。不满足时，可能退化为二分查找甚至链式 if-else，性能反而更差。
常见触发跳转表的条件：
- case 标签值是密集整数（如 0,1,2,3,5,6 —— 缺 4 但跨度不大仍可能保留）
- 值域范围不能过大（GCC 默认阈值约 10×case 数量；Clang 更激进些）
- 所有 case 值在编译期可确定（不能含变量或非常量表达式）
- 没有大量“空洞”（gap），比如 case 1: 和 case 1000000: 并存，大概率放弃跳转表
如何确认编译器是否用了跳转表？看汇编最直接
别猜，用 -S 看汇编输出。跳转表典型特征是：一段连续的 .quad 或 .long 地址列表，紧跟着一条类似 jmp *jump_table(,%rax,8) 的间接跳转指令。
实操建议：
- GCC/Clang 加 -O2 -S 编译后搜索 jump_table 或 .quad 关键字
- 用 objdump -d 反汇编目标文件，定位 switch 对应函数段
- 若看到 cmp + je 链式比较，说明没走跳转表，而是用了决策树或线性查找
- 注意：default 分支位置会影响布局，若它逻辑重且被频繁执行，可能破坏紧凑性，导致编译器放弃跳转表
稀疏 case 怎么办？手动拆分或改用 unordered_map
当 case 是离散大整数（如 0x1001, 0x200A, 0x80FF），跳转表失效，又不想写一长串 if-else，可以主动干预：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
方案一：按高位分组 + switch 嵌套
- 先提取高 N 位做外层 switch（保证密集）
- 每个分支内再处理低位子集（数量少，用 if 或小 switch）
- 适合协议解析、状态机等有天然分层的场景
方案二：哈希映射（C++11+）
- 用 std::unordered_map<int std::function>></int> 存 handler
- 启动时一次性初始化，避免运行时构造开销
- 注意：首次调用有 hash 计算 + bucket 查找开销，不如跳转表快，但比稀疏 switch 的线性查找稳定
示例片段：
static const std::unordered_map<int, void(*)()> handlers = {
{0x1001, &handle_cmd_a},
{0x200A, &handle_cmd_b},
{0x80FF, &handle_cmd_c}
};调用时：
auto it = handlers.find(cmd); if (it != handlers.end()) it->second();
枚举类型 switch 的陷阱：别让编译器“猜错”底层类型
如果枚举值跨度大但定义时没显式指定底层类型，比如：
enum cmd_t { A = 1, B = 1000, C = 2000 };编译器可能选
int 作底层类型，但跳转表仍按值域 [1,2000] 分配 2000 项——浪费内存且易触发退化。
解决办法：
- 显式限定底层类型为最小可行宽度：enum cmd_t : uint8_t { A=1, B=2, C=3 };
- 或者用 enum class + 强制转换，确保值域可控
- 若必须保留大跨度值，优先考虑前述哈希方案，而非依赖编译器优化
另一个坑：default: 分支若包含 throw 或复杂逻辑，某些编译器会拒绝生成跳转表，改用更保守的实现。简单 return 或空语句更安全。
立即学习“C++免费学习笔记（深入）”；
跳转表不是银弹，它的存在取决于常量密度与编译器策略。真正影响性能的，往往是 case 值的分布特征和编译器能否静态推断出紧凑性——而不是你写了 switch 这个关键字本身。
