防御式设计重在源头减异常、精准捕获与可控响应：接口边界三重校验输入，资源调用预设超时熔断，分层捕获业务/系统异常，并发场景用结构化工具与状态断言加固容错。
防御式设计不是把异常兜住就完事，而是从源头减少异常发生的可能性，并让剩下的异常能被快速识别、精准拦截、可控响应。真正提升稳定性的一个量级，关键不在“捕得多”，而在“抛得少”和“捕得准”。
输入与参数层面的主动拦截
大多数运行时异常源于未经校验的外部输入。防御式设计的第一步是把校验前移到接口边界，而不是等空指针或类型转换失败后再处理。
- 对所有入参做非空、范围、格式三重检查，比如年龄限制在0–150、邮箱必须含@、JSON字段不为空字符串
- 用不可变对象或构建器模式封装参数，避免中途被篡改导致状态不一致
- 前端传参不信任后端校验，后端也不依赖前端过滤——双方都做，但后端校验是最后一道防线
资源与调用链路上的失效预防
网络超时、数据库连接中断、文件句柄耗尽等不是“异常场景”，而是常态。防御式设计要把它们当作可预期事件来建模。
- HTTP调用必设超时（connect/read/write），并配置熔断降级策略，而非仅靠try-catch兜底
- 数据库查询强制分页限制（如maxPageSize=1000），避免OOM或慢SQL拖垮整个服务
- 文件/流操作统一用try-with-resources或defer释放，不依赖GC回收时机
异常分类与捕获结构的精细化分层
粗粒度的全局catch会掩盖问题本质；过度分散的局部try又增加维护成本。防御式设计强调按责任分层捕获：
- Controller层捕获业务异常（如UserNotFoundException），返回404或友好提示，不暴露堆栈
- Service层捕获系统异常（如SQLException、TimeoutException），记录ERROR日志+关键上下文（traceId、用户ID、参数摘要）
- 基础设施层（如DAO、Client）只抛出带语义的自定义异常，不抛原始Checked/Unchecked异常
并发与状态管理中的容错加固
多线程、异步任务、共享状态是异常高发区。防御式设计需结合结构化并发与状态契约。
- 用errgroup、StructuredTaskScope等作用域化并发工具，确保子任务异常可传播、可取消、不静默丢失
- 对共享变量加读写锁或使用原子类，避免竞态导致的非法状态（如余额为负、库存超卖）
- 关键状态变更前插入断言（assert），例如“更新订单前，订单状态必须为WAIT_PAY”
