throw异常是落实Fail-Fast原则的核心手段，需在前置校验、依赖调用失败、状态不一致时主动抛出语义明确的业务异常，并通过统一异常处理器映射为对应HTTP状态码。
在 API 架构设计中，throw 异常是落实 Fail-Fast 原则最直接、最有效的手段之一。它的核心不是“随便抛”，而是有策略地在错误刚露头时就中断流程，避免错误被掩盖、传递或放大，从而让问题暴露得早、定位得准、修复得快。
前置校验阶段主动 throw
API 入口处应完成关键约束的即时检查，不等业务逻辑深入就终止非法请求：
- 参数非空、格式（如手机号正则）、范围（如分页 size ≤ 100）、枚举合法性等，用
Objects.requireNonNull()或自定义校验工具，在 Controller 或 DTO 的@Valid后立即 throwIllegalArgumentException或业务异常（如BadRequestException） - 避免把 null 判断留到 Service 层再做——那已算“延迟失败”，违背 Fail-Fast
- 示例：接收用户 ID，若为负数，立刻 throw，不进入数据库查询逻辑
依赖调用失败时不吞异常、不静默降级
对非容错型依赖（如核心账户服务、支付网关），调用失败应原样或包装后 throw，而非 try-catch 后返回默认值或空对象：
- Fail-Fast 要求“失败即可见”，不是“失败即忽略”；静默处理会让上游误以为成功，导致状态不一致
- 例如：调用风控服务鉴权失败，应 throw
AccessDeniedException，而不是 catch 住并继续走下单流程 - 注意区分场景：若该依赖属于可选分支（如埋点日志上报），才适用 Fail-Safe；主链路依赖必须 Fail-Fast
状态不一致时果断 throw
业务规则冲突或数据状态矛盾，是典型需 Fail-Fast 的信号：
立即学习“Java免费学习笔记（深入）”；
- 订单已支付却收到重复支付请求 → throw
IllegalStateException - 库存扣减前发现实际库存不足 → 不走后续创建履约单逻辑，立刻 throw
InsufficientStockException - 避免用 if-else 分支绕过问题，更不能靠下游兜底——Fail-Fast 要求“错在哪儿，停在哪儿”
异常类型与层级要明确、可捕获
throw 不是目的，让调用方能精准识别和响应才是关键：
- 避免泛滥使用
RuntimeException，应定义语义清晰的业务异常类（如OrderAlreadyShippedException），继承自统一基类 - HTTP 层统一异常处理器（@ControllerAdvice）将不同异常映射为对应 HTTP 状态码（400/403/409/500），前端或调用方能按码决策
- 日志中记录异常堆栈 + 关键上下文（如订单号、用户 ID），便于快速归因
