多层容错架构通过分层拦截异常、舱壁隔离资源、状态快照与可重入设计、可观测闭环实现故障自愈，而非依赖不报错。

微任务执行链中报错导致崩溃，本质是异常未被隔离、未被收敛、未被兜底。多层容错架构不是靠“不报错”来规避崩溃，而是通过分层设防，让错误在可控范围内终止传播、降级处理或自动恢复。

分层拦截异常，阻断雪崩链路

微任务链（如 Promise.then 链、async/await 调用链、消息队列消费链）一旦某环节抛出未捕获异常，极易沿调用栈向上冒泡或向下游扩散。多层架构需在每一层明确异常边界：

• 接入层：对入参校验失败、鉴权失败等前置错误直接返回结构化响应，不进入后续微任务链
• 服务编排层：使用带超时与熔断的调用代理（如 Resilience4j 的 CircuitBreaker + TimeLimiter），单个微服务调用失败不中断整个流程
• 任务执行层：每个微任务封装为独立执行单元，统一包裹 try-catch + traceId 日志 + 降级返回（如返回缓存值、空对象或默认策略），禁止异常穿透到上层调度器

用舱壁模式隔离资源与依赖

避免一个微任务因依赖故障（如数据库慢查、第三方接口超时）拖垮整条链甚至整个线程池：

• 为不同业务域的微任务分配独立线程池或协程组，资源不共享、故障不传染
• 对关键外部依赖（如 Redis、MQ、HTTP 客户端）启用连接池隔离和请求级超时，防止连接耗尽或线程挂起
• 异步任务消费时，按 topic 或业务类型划分消费者组，单组异常不影响其他组持续拉取

引入状态快照与可重入设计

微任务常涉及状态变更（如库存扣减、订单状态流转），若执行中途崩溃，重复触发会导致数据不一致或重复操作：

• 任务启动前写入幂等记录（如 DB 中 status=‘processing’ + traceId），崩溃后可通过定时扫描补全或告警人工介入
• 关键步骤采用“先写日志再执行”（Write-Ahead Log），确保状态变更可回放或跳过
• 所有微任务入口支持携带唯一 businessId 和 version，服务端校验已处理则直接返回结果，不重复执行

构建可观测闭环，实现故障自愈

仅靠防御不够，需让系统具备感知—决策—动作能力：

• 每层埋点采集成功率、延迟、错误码分布，当某类微任务错误率突增时，自动触发降级开关（如跳过非核心校验步骤）
• 结合链路追踪（如 SkyWalking、Jaeger），定位异常高发节点，配合混沌工程定期注入延迟、OOM 等故障验证恢复逻辑
• 对频繁失败的微任务，动态切流至影子队列或降级通道，并推送根因分析建议（如“近5分钟 DB 连接超时占比82%，建议扩容连接池”）