异步编程中异常链路追踪是刚需，必须解决上下文透传、异常捕获归因、链路可视化还原三件事：统一traceid、跨线程/服务透传mdc、各阶段主动登记异常、结构化埋点生成树状图，并区分重试与超时标记。
异步编程中异常链路追踪不是“能不能做”的问题，而是“不做就难以定位”的刚需。主线程和子任务常跨线程、跨协程、跨服务运行，异常一旦发生，原始堆栈极易断裂，日志分散，重试与超时叠加后更难还原真实因果。真正有效的方案必须同时解决三件事：上下文透传、异常捕获归因、链路可视化还原。
traceId 与上下文透传是基础
没有统一 traceId，所有后续追踪都是空中楼阁。在 Spring 生态中，需确保 @Async 方法调用前已注入 MDC（Mapped Diagnostic Context），并在线程切换时显式传递：
- 使用 TransmittableThreadLocal 替代普通 ThreadLocal，避免子线程丢失上下文
- @Async 方法内部手动调用 MDC.setContextMap(MDC.getCopyOfContextMap())，尤其在自定义线程池场景下
- 微服务间调用需通过 HTTP header（如 X-B3-TraceId）或 RPC 协议头透传，下游服务启动时主动还原 MDC
异常必须被捕获并注入链路节点
异步任务的异常默认不抛出到调用方，也不会自动记录到主链路。关键动作是让每个异步阶段主动“登记”自己的失败：
- CompletableFuture 使用 .exceptionally() 或 .handle() 捕获异常，并将 error message、stack trace、当前 stage 名称、耗时一并写入链路日志
- Python asyncio 中，task.add_done_callback() 是可靠入口，回调内调用 task.exception() 获取异常对象，再关联到当前 span
- C# 的 Task 不建议只 await 后 try-catch，应在 ContinueWith(TaskContinuationOptions.OnlyOnFaulted) 中统一处理，避免遗漏未 await 的 task
链路树状图生成依赖结构化埋点
可视化不是简单聚合日志，而是还原任务间的依赖关系。每个异步节点需至少记录四项元数据：
- spanId：当前任务唯一标识
- parentId：父任务 spanId（根任务为 null）
- startTime / endTime：精确到毫秒的时间戳
- status：SUCCESS / FAILED / CANCELLED，并附带异常分类（如 TimeoutException、IOException）
有了这些字段，ELK 或 Prometheus + Grafana 就能渲染出可展开/折叠的树状图；更进一步，可基于 spanId → parentId 关系构建 DAG 图，直观显示并行分支、阻塞依赖与失败传播路径。
重试与超时需独立标记，避免掩盖真实根因
一次失败后若自动重试三次才成功，链路图里若只显示“最终成功”，就失去了诊断价值。正确做法是：
- 每次重试生成新 spanId，但共享同一 traceId 和 parentSpanId，标注 retry_attempt: 1/2/3
- 超时任务（如 CompletableFuture.orTimeout()）触发的 TimeoutException 应与业务异常区分，打标 timeout:true，并在 UI 中以虚线边框+红色闪烁提示
- 链路评估指标中单独统计 “retry_rate” 和 “timeout_ratio”，而非混入整体错误率
