应避免将业务规则误作系统异常，余额不足等属正常流程分支，宜用运行时异常如BusinessException统一处理；基础设施异常需封装为带上下文的运行时异常；跨语言场景下受检异常无法传递语义，网关层应统一转换为标准响应体；仅在契约强制恢复的极少数场景才使用受检异常。
受检异常与业务逻辑设计存在天然耦合，但这种耦合多数时候是反模式的——它把技术约束强加给业务表达，让“流程分支”误判为“系统故障”，反而掩盖真实意图。
业务规则 ≠ 系统异常
当用户余额不足、库存已售罄、订单状态不合法时，这些不是程序出错，而是业务流程的正常分支。用受检异常包装这类场景，会迫使调用方写大量 try-catch 去“处理错误”，实则只是切换到另一条业务路径。这混淆了语义：本该由 if-else 控制的流程，被扭曲成异常流，代码可读性下降，监控指标失真（错误率虚高），日志中充斥着本不该标记为“error”的记录。
- “余额不足”应抛
BusinessException.with(ErrorCode.INSUFFICIENT_BALANCE)，而非InsufficientBalanceCheckedException - Controller 层统一捕获该运行时异常，返回
{code: 4002, msg: "余额不足"}，HTTP 状态码仍为 200 或 400，不触发告警 - 真正需要显式恢复的场景极少：如银行转账失败后必须人工复核，才值得用受检异常锁定调用方必须处理
分层封装弱化异常语义
基础设施层（DB、HTTP、文件）抛出的受检异常（如 SQLException、IOException）本质是外部不确定性，但它们不应穿透到业务层。领域服务应将其转为带上下文的运行时异常，例如：
- DAO 层捕获
SQLException，包装为DataAccessException("查询用户订单失败", orderId) - Service 层不再声明 throws，也不暴露原始异常类型，只在必要时抛
OrderClosedException(orderId) - 这样既保留关键业务字段（便于日志提取和链路追踪），又避免上层被迫处理与业务无关的技术细节
跨语言与网关契约冲突
现代系统多为异构架构，Java 的受检异常在 Dubbo 序列化中仅保留 message 和 cause，类型信息丢失；前端、Go 或 Python 客户端根本无法识别 InvalidCouponException 是否受检。所有对外接口最终都靠 HTTP 状态码 + 自定义 error code 通信。强行使用受检异常，等于在 Java 单侧构建一套无法外溢的语义体系，徒增维护成本。
- 网关层（Controller / Feign Client）应作为异常终结点：捕获一切异常，统一映射为标准响应体
- 响应体中
code字段来自枚举（含是否可重试、是否需人工介入等元信息），不依赖异常类名 - 敏感字段（如银行卡号、身份证号）不在异常 message 中拼接，防止日志泄露
真正需要受检异常的边界场景
不是禁用，而是严控范围。只有当失败意味着契约断裂、且调用方有明确恢复动作时，才保留受检异常：
- 开放 SDK 给第三方：如支付回调确认失败，必须要求调用方实现补偿逻辑，此时
CallbackConfirmFailedException强制其throws或try-catch - 金融核心流程：某清算步骤依赖外部监管接口，超时后需走人工审批通道，该异常必须中断默认流程并引导至特定处理分支
- 遗留系统桥接：老协议规定“配额超限”必须返回特定错误码且不可忽略，封装为受检异常并附清晰 Javadoc，比运行时异常更能传递契约意图
