卫语句通过提前返回或抛出异常处理边界情况，剥离异常路径，使主逻辑清晰简洁；每个卫语句只负责一个明确拒绝理由，不跟else，按失败概率排序，避免合并判断或破坏语义。
嵌套过深的 if-else 判断链会让代码难以阅读、修改和测试。卫语句（Guard Clause）不是替代所有条件分支的银弹，而是通过提前返回或中断流程，把“异常路径”或“边界情况”快速剥离出去，让主干逻辑更清晰。
卫语句的核心：先处理退出条件，再写主逻辑
关键不是“少写 else”，而是把干扰主流程的检查提前做、早结束。主逻辑自然缩进减少，可读性提升明显。
- 每个卫语句只负责一个明确的拒绝理由（如参数为空、状态不合法、权限不足）
- 卫语句后不跟 else，直接写主业务逻辑，避免“else 套 else”
- 返回值或抛出异常要一致：函数统一返回 void / null / error；方法统一 throw IllegalArgumentException 或自定义异常
识别适合抽成卫语句的场景
以下情况优先考虑卫语句重构：
- 参数校验（null、空字符串、负数、非法枚举值）
- 前置状态检查（用户未登录、订单已关闭、库存不足）
- 权限/角色判断（非管理员跳过、无编辑权限直接拒）
- 短路条件（缓存命中直接返回，无需继续查库）
重构时注意的三个细节
容易忽略但影响效果：
- 顺序很重要：按失败概率从高到低排列卫语句（比如 null 检查通常比范围检查更常触发）
-
别合并多个判断：
if (a == null || b == null || c 看似简洁，但报错信息模糊、调试困难；拆成独立卫语句更利于定位 - 别为了卫语句而牺牲语义：如果两个条件天然耦合（如“用户存在且已激活”），强行拆开反而增加理解成本，保持为一个判断更合适
一个典型重构对比
重构前（4 层嵌套）：
if (user != null) {
if (user.isActive()) {
if (order != null && order.getStatus() == OPEN) {
if (inventoryService.hasStock(order.getItemId(), order.getQuantity())) {
return processOrder(order);
} else {
throw new InsufficientStockException();
}
} else {
throw new InvalidOrderStatusException();
}
} else {
throw new InactiveUserException();
}
} else {
throw new UserNotFoundException();
}
重构后（零嵌套，主逻辑一目了然）：
if (user == null) throw new UserNotFoundException();
if (!user.isActive()) throw new InactiveUserException();
if (order == null || order.getStatus() != OPEN) throw new InvalidOrderStatusException();
if (!inventoryService.hasStock(order.getItemId(), order.getQuantity()))
throw new InsufficientStockException();
return processOrder(order); // 主流程干净浮现
不复杂但容易忽略。卫语句的价值不在炫技，而在降低认知负荷——让读代码的人一眼看清“什么情况下这事根本不会发生”，剩下的，才是重点。
