必须用 if/else 而非 switch 的情况包括：数值范围判断（如 score >= 90）、关系运算（>、
if/else 适合范围判断和复杂逻辑，switch 专用于同一变量的离散值等值匹配——别硬套语法，先看条件本质。
什么时候必须用 if/else 而不是 switch
当条件涉及以下任一情况时，switch 根本无法替代 if/else：
- 数值范围判断（如
score >= 90、age ） - 多变量组合（如
if (user && user.role === 'admin' && !user.isBlocked)） - 类型或存在性检查（如
if (typeof data === 'object' && data?.id)） - 空值/假值判断（如
if (input?.trim())或if (list?.length)） - 需要提前退出（如
if (!token) return;）
强行把范围逻辑塞进 switch(true) 是反模式：可读性差、易漏 break、IDE 和 TypeScript 都难推导类型，且现代引擎对它无优化。
switch 真正该用的场景和关键限制
只在满足全部以下条件时才优先考虑 switch：
立即学习“Java免费学习笔记（深入）”；
- 判断目标是**同一个变量或表达式**（如
status、response.code） - 所有分支都是**静态常量**（字符串字面量、数字、
Symbol，不支持config.mode这类动态值） - 分支数 ≥ 4，且值互斥、覆盖明确（如 HTTP 状态码、订单状态枚举）
必须注意的坑：
-
case使用===严格相等，null、undefined、NaN都不会匹配到case 0:这类写法 - 漏写
break会穿透执行下一个case，静默出错，极难调试 -
default不是可选的“锦上添花”，而是防止逻辑遗漏的必需兜底
比 if 和 switch 更优雅的替代方案
当分支逻辑变多、需复用或未来可能扩展时，硬写链式 if 或长 switch 反而更难维护：
- 分支对应不同函数调用？用
Map：const handlers = new Map([['save', saveData], ['delete', deleteItem]]);<br>handlers.get(action)?.();
- 分支值来自 API 或配置？用查找对象：
const statusText = { pending: '加载中', success: '成功', error: '失败' };<br>return statusText[status] ?? '未知状态'; - 分支含副作用或异步操作？拆成小函数 + 提前
return，比嵌套if清晰得多
真正卡住人的从来不是语法会不会写，而是判断「这个条件未来是否稳定」「分支是否真互斥」「值来源是否可信」——比如一个 switch 刚写完，PM 就说下周要加两个新状态，那不如一开始就用 Map 或策略对象。
