switch的case必须为编译期整型常量，字符串/浮点数不可用；default非可选而是防崩底线；fall-through需显式标注；性能优势仅在稀疏整型值稳定成立；条件表达式只求值一次。
switch 的 case 标签只能是常量表达式
很多人写 switch 时想用变量、函数返回值或字符串当 case，直接报错：error: case label does not reduce to an integer constant。C++ 要求每个 case 后必须是编译期可确定的整型常量（含 constexpr）、枚举值，或能隐式转为整型的字面量。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
enum class定义状态码，比裸数字更安全、可读性更好 - 字符串匹配不能直接用
switch，得转成哈希值（如std::hash<:string>{}(s)</:string>）再配合constexpr字符串哈希（C++20 起可行），但多数场景直接用if-else if更稳妥 - 浮点数禁止作为
switch条件——连比较都容易出错，更别说做分支跳转
default 分支不是可选项，而是防崩底线
漏写 default 不报错，但一旦 switch 表达式的值没被任何 case 覆盖，程序就静默跳过整个块，可能引发逻辑空转、未初始化变量使用等隐蔽问题。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 哪怕你“确定”所有情况都已覆盖，也强制写
default，至少加个assert(false)或抛异常（如throw std::runtime_error("unhandled switch value")） - 在调试构建中，
default里打日志输出实际值，能快速暴露枚举扩展后忘记更新switch的问题 - 某些静态分析工具（如 clang-tidy）会警告缺失
default，把它当成编译要求来对待
fall-through 必须显式标注，否则编译器会警告
C++17 起，编译器默认把无 break 的连续 case 当作潜在错误，GCC/Clang 会报 implicit-fallthrough 警告。这不是风格问题，是防止误写漏 break 导致意外穿透。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 真需要穿透，必须写
[[fallthrough]];（C++17）或注释// fall through（兼容旧标准） - 不要依赖 “看起来像一组” 就省略
break；比如处理多个错误码映射到同一行为，每个case后仍要明确写[[fallthrough]]; - VS2019+ 默认开启该警告，GCC/Clang 加
-Wimplicit-fallthrough即可捕获
switch 性能优势只在稀疏整型值上稳定成立
编译器对 switch 的优化（跳转表、二分查找）高度依赖 case 值的分布。如果 case 是 1, 2, 5, 1000, 1000000 这种跨度极大又稀疏的整数，生成的代码可能比一长串 if-else if 还慢，甚至退化为线性比较。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 别盲目迷信 “
switch一定比if快”；用perf或 VTune 实测关键路径，尤其注意编译器是否真生成了跳转表（看汇编里的jmpq *xxx(,%rax,8)类指令） - 若值域集中（如 0–15 的状态码），
switch几乎总赢；若来自用户输入或外部协议，且范围不可控，优先保证逻辑清晰，再谈优化 - 模板 + constexpr 递归展开（C++14 起）可替代部分运行时
switch，但仅适用于编译期已知的分支集合
最易被忽略的一点：switch 的条件表达式只求值一次，而 if-else 中每个条件都要单独计算。如果判断逻辑开销大（比如调用函数），这个差异会真实影响行为和性能，别只盯着 case 写法本身。
