异常上下文指抛出异常瞬间可追溯的关键变量与状态，如user_id、order_id、api_path、db_query等现场快照；缺失则导致排查困难。应通过带cause构造异常、显式拼接业务字段、避免依赖MDC或无意义wrap来保障上下文完整性。
异常上下文到底指什么
就是抛出异常那一瞬间，程序里哪些变量、状态、调用链路是「已知且可追溯」的。不是日志时间戳或进程 ID，而是能直接帮人定位“为什么这里崩了”的那几样东西：user_id、order_id、http_method、api_path、db_query（如果已拼好）、甚至 retry_count。它们共同构成异常发生时不可复现的现场快照。
不放关键变量=让排查变成盲人摸象
常见错误现象：NullPointerException 报在 userService.updateProfile()，但没带 userId；SQLIntegrityConstraintViolationException 出现在插入订单，却看不到 orderNo 或 payAmount。结果是：翻日志要手动关联上下游，查监控得猜时间窗口，重启服务后现场消失。
实操建议：
- 捕获异常后，用
String.format()或logger.error("msg", e)的变体把关键变量塞进 message，例如：logger.error("fail to update profile for user {}, cause: {}", userId, e.getMessage(), e) - 避免只拼接
e.toString()—— 它不含业务字段，且可能被 logback 截断 - 不要依赖 MDC（Mapped Diagnostic Context）自动注入——它依赖线程上下文，在异步、RPC、线程池场景下极易丢失
Java 中 Throwable 的 fillInStackTrace() 会吞掉上下文
很多人以为 new 一个新异常再 throw 就行，比如：throw new RuntimeException("update failed")。这会丢掉原始堆栈和所有上下文信息。更糟的是，有些框架（如 Spring AOP）会在代理层重新包装异常，进一步擦除原始现场。
实操建议：
- 优先用带 cause 的构造函数：
throw new ServiceException("update failed for " + userId, e) - 如果必须新建异常，至少保留原始
cause和关键字段，别只留空字符串 - 检查你用的 RPC 框架（如 Dubbo、gRPC）是否默认序列化
Throwable全字段——很多只传message和stackTrace，suppressed和自定义字段全丢
Go 的 error wrap 和 fmt.Errorf("%w") 容易漏掉 context
Go 1.13 引入了 error wrapping，但 fmt.Errorf("failed to process %s: %w", key, err) 只保留了 key 字符串，原始 error 里的 userID、traceID 等结构体字段不会自动透出。
实操建议：
- 自定义 error 类型时，显式实现
Error()方法并拼入上下文字段，例如返回fmt.Sprintf("user %s: %v", e.userID, e.err) - 用
errors.As()提取底层 error 时，记得同时取它的上下文字段，而不是只看顶层 message - 避免在中间层无意义地 wrap：比如 HTTP handler 里
return fmt.Errorf("handler error: %w", serviceErr)，不如直接返回serviceErr并确保它本身已含 context
上下文不是越多越好，而是要在抛出点就决定“谁会看这个异常”——运维看日志要 traceId，开发查问题要 inputParams，DBA 分析慢查询要 sql 和 bindValues。漏一个，就多花十分钟翻三份日志。
