用好if-else的关键是逻辑清晰、易于维护：优先使用守卫语句提前拦截异常，用有意义的布尔变量封装复杂条件，避免嵌套深渊和空else陷阱，状态分支多时改用策略模式或查表法。
用好 if-else，关键不是写对语法，而是让判断逻辑一目了然、容易维护。业务代码里最怕“嵌套深渊”和“条件迷宫”，清晰的结构比炫技更重要。
把核心判断条件提前暴露
别把关键业务规则藏在层层缩进里。优先用 guard clause（守卫语句） 快速拦截异常或边界情况，主流程自然聚焦正常路径。
- 比如处理订单前，先检查用户是否登录、库存是否充足、支付是否超时——任一不满足就直接 return 或抛错
- 这样主干代码不用缩进，读起来像自然语言：“如果都 OK，才走创建订单逻辑”
- 避免写成：if (登录) { if (库存) { if (未超时) { ... } } }
用有意义的布尔变量封装复杂条件
当判断条件变长（比如 status === 'active' && !isExpired && user.tier >= 2 && !hasPendingRefund），别让它直接出现在 if 后面。
- 提前计算并命名：const canApplyDiscount = status === 'active' && !isExpired && user.tier >= 2 && !hasPendingRefund;
- 后续 if 就变成 if (canApplyDiscount) { ... }，意图立刻可读
- 这个变量还能复用、单独测试、加注释说明业务含义
避免 else 的“默认兜底”陷阱
else 容易成为“什么都没想清楚就塞进去”的地方。业务上很少真有“其他所有情况都一样处理”的场景。
- 如果 else 分支存在，尽量明确写出它的触发条件（哪怕用注释），例如：// else: 订单状态为 'cancelled' 或 'refunded'
- 考虑用 else-if 显式列出常见分支，末尾用 else 报错或打日志，提醒“遇到未预期状态”
- 警惕空 else：只写 else { } 或 else { continue; } 往往意味着逻辑遗漏
业务状态多时，优先考虑策略模式或查表法
当 if-else 链超过 4–5 个分支，且每个分支执行不同业务动作（比如按订单类型走不同审核流），硬写 if-else 会越来越难改。
- 把分支逻辑抽成函数，用对象映射状态到处理器：const handlers = { 'cash': handleCashOrder, 'credit': handleCreditOrder, ... };
- 调用时只需 handlers[order.type]?.(order) || throwUnknownTypeError();
- 新增类型不改原逻辑，只加一行映射，也方便单元测试覆盖每种类型
不复杂但容易忽略：清晰的 if-else，本质是把业务规则翻译成人能快速看懂、机器能准确执行的语言。
