必须用try-catch强行隔离分治子任务异常，以保障对账结果的原子性、可追溯性与业务确定性；未隔离会导致T+1报表延迟、资金差异漏报、审计断链等严重后果。
在财务对账组件中，必须用 try-catch 强行隔离分治子任务的局部异常，根本原因不是为了“兜住错误”，而是保障对账结果的原子性、可追溯性与业务确定性。对账不是普通计算——一笔差额未定位，可能意味着资金错付、监管报备失真或客户投诉溯源失败。若子任务（如某商户日结比对、某通道流水重算）因空指针、json解析失败、数据库连接超时等异常直接中断整个对账流程，轻则重跑耗时数小时，重则导致t+1报表延迟、资金池头寸误判。
分治结构天然放大异常传播风险
财务对账普遍采用分治策略：按商户、渠道、日期、币种切片并行执行。这种设计提升吞吐，但也带来两个关键脆弱点：
- 各子任务运行环境独立（不同数据源连接池、线程上下文、缓存状态），一个子任务的资源泄漏或状态污染不会直接影响其他子任务，但未捕获的异常会穿透 ExecutorService 的 Future.get() 或 CompletableFuture，导致主线程提前终止
- 对账主流程需汇总所有子任务的比对结论（一致/差异/失败/跳过）。若某个子任务抛出 RuntimeException 后未被拦截，其返回值缺失，汇总逻辑无法区分“该子任务确实无数据”和“该子任务崩溃了”，造成结果不可信
Try-catch 是实现“异常可控降级”的最小必要手段
这里“强行隔离”不是粗暴吞掉异常，而是建立明确的失败契约：
- 每个子任务 Runnable/Callable 必须包裹独立 try-catch，捕获后统一转换为标准失败对象（如
ReconciliationResult.failed(taskId, e)），确保返回类型稳定，主流程可安全调用get()获取结果 - 对不同异常分类响应：NullPointerException、ClassCastException 等编码类异常立即标记为 FATAL 并记录堆栈；SQLTimeoutException、HttpClientErrorException 等外部依赖异常标记为 TRANSIENT，允许主流程后续重试该子任务而非整批重跑
- catch 块内必须完成关键副作用隔离：清空本子任务持有的临时缓存、关闭专属数据库连接、释放本地文件句柄——避免异常残留状态污染后续子任务
不隔离的后果远超日志报错
看似只是“多打几行 catch”，实际影响业务连续性：
- 对账窗口超时：某支付通道子任务因证书过期抛出 SSLHandshakeException，未捕获 → 整个对账线程池被阻塞 → 其他正常子任务等待超时 → T+0 对账失败，触发人工介入流程
- 差异漏报：某商户子任务因 JSON 字段名变更抛出 JsonParseException，未隔离 → 该商户结果为空 → 汇总逻辑默认视为“一致” → 实际存在 50 万元资金差异未告警
- 审计断链：异常子任务未记录原始请求参数、响应快照、执行耗时，事后无法复现问题场景，违反金融系统“可回溯”强合规要求
配套动作让隔离真正生效
仅靠 try-catch 不够，需三者协同：
-
统一异常包装器：所有子任务 catch 块末尾调用
TaskFailure.wrap(e, context)，注入 taskId、批次号、执行节点 IP，写入结构化日志（ELK 可检索） -
失败子任务熔断开关：在共享配置中心设置
recon.fault-tolerance.max-failures-per-task=3，单个子任务连续失败三次后自动加入本次对账黑名单，避免反复失败拖垮整体 - 主流程兜底校验：汇总阶段检查子任务结果集 size 是否等于预期分片数，若不等，立即告警并暂停生成最终报告，强制人工确认缺失原因
