C++ switch仅支持整型和枚举，std::string等类型不可直接使用；需用if-else或C++17的string_view哈希转换；fall-through需显式标注[[fallthrough]]；default不应省略；性能取决于case数量与分布。
switch 只能用整型或枚举，std::string 不能直接进 switch
这是最常卡住人的地方：C++ 的 switch 底层依赖跳转表（jump table），要求 case 标签必须是编译期可确定的整数常量。所以 char、int、enum 没问题，但 std::string、double、std::vector 一律不行。
常见错误现象：error: switch quantity not an integer 或类似提示，尤其在你把 std::string 变量直接塞进 switch 括号里时。
- 如果真要按字符串分支，老实用
if-else if配合.compare()或== - C++17 起可用
std::string_view+constexpr哈希（比如std::hash<:string_view>{}</:string_view>）手动映射成整数，再进switch，但得自己写哈希函数且保证无冲突 - 枚举类型最安全：定义
enum class Command { Start, Stop, Pause };，然后switch (cmd)就很干净
case 后面不加 break 会“掉进”下一个分支
这不是 bug，是 C++ 的设计行为，叫“fall-through”。但绝大多数时候它是个隐藏陷阱——尤其当人写完一个 case 忘记加 break，结果后续几个分支全被执行了。
使用场景：只有明确需要连续执行多个 case 时才省略 break，比如处理范围：case 1: case 2: case 3: 共享同一段逻辑。
立即学习“C++免费学习笔记（深入）”；
- 现代编译器（如 GCC/Clang）加
-Wimplicit-fallthrough会警告没写[[fallthrough]];的情况 - 想显式表示“这里故意不 break”，就在
case结尾加[[fallthrough]];（C++17） - 别依赖注释代替
[[fallthrough]]，编译器不认注释，IDE 也难高亮
default 不是可选的，漏掉可能掩盖逻辑缺陷
很多教程说 “default 是可选的”，但实际工程中，不写 default 往往意味着你没想清楚所有输入可能。一旦值超出所有 case 范围，程序就静默跳过整个 switch，容易引发未定义行为或逻辑错位。
性能影响几乎为零，但兼容性和可维护性差别很大——尤其变量来自外部输入（如用户命令、网络包解析、配置文件读取）时。
- 哪怕只是写个
default: throw std::runtime_error("unhandled case");，也比什么都不做强 - 如果确实有合法的“无操作”分支，至少写
default: break;，让意图清晰 - 静态分析工具（如 clang-tidy）默认会警告缺失
default，尤其对enum class
switch 和 if-else 性能差多少？别猜，看场景
不是“switch 一定比 if-else 快”。编译器优化策略取决于 case 数量、分布密度和目标平台。
典型表现：
- case 少（≤3）、值稀疏（比如
case 1:,case 100:,case 1000:）→ 编译器大概率生成条件跳转，和 if-else 几乎一样 - case 多（≥5）、值密集连续（比如
0到9）→ 更可能生成跳转表（O(1)），比链式 if-else（O(n)）快 - ARM64 等架构上，跳转表还可能被放进只读数据段，缓存友好；x86 上则要看具体指令编码
真正该关心的是可读性和可维护性：当分支逻辑稳定、值有限且已知时，switch 更易一眼看清所有路径；动态、语义化强的判断（比如权限校验、状态组合）还是 if-else 更自然。
边界情况容易被忽略：带负数的 int、大范围枚举（如 0~65535）、以及 char 类型在不同平台默认是有符号还是无符号——这些都会影响 case 匹配结果，调试时得盯紧变量的实际值类型。
