超过三层嵌套的 if_else 就该考虑重构为 switch，因其可读性和维护性会断崖式下降；switch 适用于 HTTP 状态码、用户角色权限等场景，但需注意各语言特性差异及 default 分支的安全兜底作用。
if_else 嵌套到几层就该换 switch
超过三层嵌套的 if_else 就该考虑重构，不是语法不允许，而是可读性和维护性会断崖式下降。比如判断 HTTP 状态码、用户角色权限、表单字段类型等场景，用 switch 更直观。
注意：JavaScript 的 switch 只做严格相等（===），不会类型转换；而 Go 或 Rust 的 match 支持模式解构，但这里只谈传统 switch。
- PHP 中
switch对null、0、空字符串容易误判，建议先用is_string()等显式校验类型 - Python 没有
switch，别硬套elif堆砌，优先用字典映射或match（3.10+） - C/C++ 里漏写
break是经典陷阱，会意外 fall-through，Clang/GCC 加-Wimplicit-fallthrough能捕获
switch 的 case 值必须是编译期常量吗
取决于语言。C、Java、Go 要求 case 是常量表达式；JavaScript 允许任意表达式，但实际运行时仍按值匹配，不是动态计算分支逻辑。
常见误用：把函数调用或变量直接当 case 值写进去，以为能“动态 dispatch”，其实只是计算一次后静态匹配。
- Java 中
case不能是String变量（只能是字面量或final静态字段） - JS 中
switch (x)的x是运行时值，但每个case仍需是确定值，不支持case x > 5:这种条件写法 - Rust 的
match支持范围（1..=5）、守卫（if x % 2 == 0），但传统switch不行
if_else 和 switch 在性能上有差别吗
现代编译器/解释器大多会把简单 switch 编译成跳转表（jump table），O(1) 查找；密集整数 case 效率通常高于等价的 if_else 链（后者最坏 O(n)）。但差别只在高频路径上明显，日常业务代码几乎感知不到。
真正影响性能的是分支预测失败——CPU 猜错下一条指令，导致流水线冲刷。无论 if 还是 switch，如果分支概率极不均衡（比如 99% 走 default），都可能拖慢执行。
- Go 的
switch在 case 数少于 5 个时，编译器可能直接生成 if-else，不优化 - JS 引擎（V8）对
switch有特殊优化，但若 case 值跨度太大（如case 1:和case 999999:），反而退化为哈希查找 - 别为了“理论上快”强行改写逻辑，先 profile，再决定要不要动
default 分支不是可选项，是安全底线
没写 default 的 switch，和没写 else 的 if_else 一样危险——漏掉未覆盖的输入，轻则逻辑跳过，重则静默错误或崩溃。
尤其处理外部数据（API 返回、用户输入、配置文件）时，枚举值随时可能新增，default 是你最后的兜底。
- Java 编译器不强制
default，但启用-Xlint:fallthrough和-Xlint:switch可警告遗漏 - TS/JS 中，用
assertNever(x: never)类型守卫让default分支报错，确保所有 union 成员都被处理 - C 中，
default里加assert(0)或__builtin_unreachable()，帮编译器识别“此处不该到达”
