silent failure 的根源是异常被吞掉或无人响应，而非抛出异常本身；应通过语义化容器、分层拦截、强制可观测和启动期阻断等机制确保失败可见可追踪。
直接 throw 异常本身不是问题，关键在于抛出后是否被合理承接、传递和响应。Silent Failure 的根源不是“抛异常”，而是“异常被吞掉”或“抛了没人管”。架构设计中要做的，是让异常路径可见、可追踪、可决策，而不是消灭异常。
用语义化容器替代裸 throw + null
避免在业务逻辑中 throw 后返回 null 或 void，导致调用方无法感知失败。改用显式承载失败语义的类型：
-
Optional
：适用于“无结果即正常失败”的场景（如查询不存在），但注意 Optional 不能表达错误原因 -
Result
（如 vavr Try、自定义 Result）：封装成功值或具体异常，强制调用方处理两种分支 -
ResponseEntity
（Spring Web）：HTTP 层统一包装状态码与业务错误码，避免 controller 中 try-catch 吞异常
分层拦截异常，拒绝静默吞没
每一层都应明确自己对异常的责任边界：
- 数据访问层（DAO）：不吞 SQLException，原样或包装为 DataAccessException 抛出
- 服务层（Service）：捕获底层异常，转换为领域级异常（如 InsufficientBalanceException），并记录关键上下文日志
- 接口层（Controller/Endpoint）：全局异常处理器统一响应格式，但绝不 catch 后 return null 或空对象
强制失败可观测，而非仅靠日志
日志只是辅助，真正规避 silent failure 需要机制保障：
- 所有非预期异常必须触发监控告警（如 Prometheus + AlertManager 捕获未处理的 RuntimeException）
- 关键路径添加断路器（如 Resilience4j），失败达到阈值时主动熔断并上报，而非持续静默重试
- 对“旁路逻辑”（如异步发消息、打日志）使用 Fail-Safe 策略，但需单独埋点统计失败率，确保降级行为本身可被发现
静态初始化与启动期异常必须阻断
类加载或 Spring Context 初始化阶段的异常，绝不能静默降级：
- static 块中禁止 IO、网络、复杂解析；若必须，捕获后 throw RuntimeException 并带清晰提示，让应用启动失败——这比运行时随机 NPE 更安全
- @PostConstruct 方法中抛异常会阻止 Bean 注册，这是正确行为，不应 try-catch 吞掉
- Spring Boot 的 ApplicationRunner / CommandLineRunner 失败应终止进程（默认行为），避免“看似启动成功实则核心功能缺失”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
