java受检异常处理需遵循局部化与全局化协同原则：局部处理聚焦可现场恢复、含业务语义的异常，明确动作；全局处理负责未捕获或跨模块异常的标准化响应与安全熔断，二者分层设防、不可替代。
受检异常处理的局部化原则与全局化策略，本质是“在哪捕、由谁管、怎么分”的问题。Java中Checked Exception必须显式处理，不能忽略，但处理位置和方式需结合业务边界与系统结构来权衡——不是所有异常都该在发生处拦截，也不是所有异常都该统一兜底。
局部化原则：精准拦截，明确责任
局部处理适用于异常原因清晰、影响范围有限、且有明确修复或降级路径的场景。它强调“谁触发、谁知情、谁可控”。
- 在Service方法内抛出IOException时，若调用方（如Controller）能立即重试、切换备用资源或返回友好提示，则应在Controller层用try-catch捕获并转化，避免向上暴露技术细节；
- 数据库操作抛出SQLException，若仅因某条记录脏数据导致，且可清洗后重入，则适合在DAO或Service内部捕获并做轻量修正；
- 局部处理必须伴随明确动作：日志记录、状态回滚、用户提示、降级响应，不能只写个空catch或e.printStackTrace()。
全局化策略：统一出口，格式收敛
全局处理不是替代局部逻辑，而是兜住那些未被提前捕获、或跨多模块共性的受检异常，确保系统不崩、响应不乱、日志可溯。
- Spring MVC中通过实现HandlerExceptionResolver或使用@ControllerAdvice，将IOException、SQLException等映射为标准JSON错误体或跳转统一错误页；
- 全局处理器应区分异常类型做差异化响应：对FileNotFoundException返回404+提示文案，对SQLTimeoutException返回503+重试建议，而非一律返回500；
- 全局层不替代业务判断，只做“标准化包装”和“安全熔断”，原始异常仍需保留堆栈供排查，不可吞掉。
协同边界：什么该局部、什么该全局？
判断关键看三点：是否可现场恢复、是否涉及业务语义、是否跨调用链。
- 可现场恢复（如网络超时后自动重试一次）→ 局部处理；
- 含业务含义（如“库存不足”“权限不足”）→ 局部转为业务异常再抛出，由全局统一渲染；
- 跨远程调用（Feign/HTTP/RPC）引发的IOException → 建议局部捕获并封装为自定义业务异常，避免底层异常穿透到表现层。
避坑提醒：别让“全局”变“万能”
常见误区是把所有异常扔给全局处理器，结果导致：
- Controller里大量throw new RuntimeException(e)，掩盖真实异常类型；
- 全局处理器里用instanceof硬判断几十种异常，维护成本飙升；
- 日志里只剩“统一错误：系统繁忙”，无法定位是DB连不上还是Redis超时。
真正健壮的设计，是局部守住关键决策点，全局守住出口一致性——两者不是二选一，而是分层设防。
