当条件分支≥6个且逻辑简单时，优先用查找表替代if-else或switch；连续小整数键用static constexpr std::array，稀疏或非整数键用std::unordered_map，但需权衡构造开销、缓存性能与线程安全。
条件分支太多且分支逻辑简单时，考虑查找表
当 if-else if 链或 switch 里有 5 个以上分支，且每个分支只做单条赋值、返回常量或调用无副作用的纯函数（比如 return 1;、return "error";），这时查表比跳转更稳。编译器对长分支链的优化有限，尤其在非热点路径上可能不内联或不预测准确，而数组/哈希表访问是可预期的内存访存行为。
常见场景包括：状态码转字符串、协议类型映射、字符分类（如 is_digit / is_space）、有限枚举值到处理函数指针的绑定。
- 分支数 ≥ 6 且键为连续小整数（如 enum）→ 用静态数组
- 键稀疏或非整数（如字符串字面量）→ 用
std::unordered_map或std::map，但注意构造开销 - 键是 char 或 uint8_t → 可直接索引 256 元素的
std::array，零成本
switch 的 case 值不连续或跨度大时，别硬扛
比如 switch (x) { case 1: ... case 100: ... case 9999: ... }，编译器可能生成跳转表+二分查找混合策略，实际性能不如显式查表。特别是当 case 值来自外部输入（如配置、网络包）且分布不可控时，跳转表可能被弃用，退化成线性比较。
此时把 case 值作为 key，预置 std::unordered_map<int std::function>></int> 或 std::array<:function>, 10000></:function>（若内存允许），能消除分支预测失败惩罚。
- 用
std::array要确保索引在合法范围内，否则需先做边界检查——这本身又引入分支，得权衡 - 用
std::unordered_map注意首次查找可能触发哈希表扩容，不适合极低延迟场景 - 若 key 是枚举，优先用
static constexpr std::array+static_cast<size_t></size_t>索引，零运行时开销
分支中调用虚函数或涉及缓存未命中时，查表未必更快
查找表不是银弹。如果表项存储的是虚函数指针或需要间接调用的对象方法，CPU 仍要经历指令缓存未命中 + 分支预测失败；如果表本身很大（比如百万级 std::array），TLB miss 和 cache line 淘汰反而拖慢速度。
典型反例：用 std::array<:function>, 65536></:function> 处理 uint16_t 输入。函数对象本身占用至少 24 字节，整个数组超 1.5MB，远超 L3 cache，随机访问极易 cache miss。
- 表大小超过几 KB 就该警惕，优先测 perf + cache-misses
- 避免在表里存
std::function，改用函数指针或模板特化 - 若原分支里有复杂计算（如
sqrt(x) + log(y)），查表只是把计算提前到初始化阶段，要确认初始化时机是否可接受
调试和热更新需求强时，查表更友好
当业务要求运行时修改分支逻辑（比如 A/B 测试、策略热切换），硬编码的 if 或 switch 必须重启，而查表只要替换 map 或重载数组内容即可。配合 constinit + constexpr 初始化，还能兼顾编译期确定性和运行期灵活性。
但要注意：全局表被多线程读写时，必须加锁或用 std::atomic 控制更新可见性；若用 std::vector 动态扩容，迭代器失效风险比分支高得多。
- 只读场景下，
static constexpr std::array最安全，编译器会把它放进 .rodata - 需要更新 → 用
std::shared_mutex保护std::unordered_map，读多写少时性价比高 - 别在信号处理函数里查非 lock-free 表，避免死锁
perf record -e cache-misses,instructions,cycles 实测，光看代码行数容易误判。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
