安全捕获异常关键变量需在异常发生现场提取：优先用自定义异常构造参数传入业务id；避免反射、tostring()等高危操作；集合只记size和前3元素；时间转iso格式；mdc存简单类型上下文并及时清理。
Java异常捕获时怎么安全获取关键变量值
不能直接在catch块里写一堆System.out.println或手动拼字符串——变量可能为null、未初始化、被JIT优化掉，或者对象太大导致日志爆炸。核心是：只取真正有助于定位问题的字段，且必须在异常发生“现场”就完成提取。
- 优先用异常构造时的上下文参数，比如自定义异常类的构造函数接收
userId、orderId等业务ID，而不是事后从栈帧里反射抓 - 避免在
catch中调用可能抛异常的方法（如toString()重写有bug、JSON.toJSONString()序列化循环引用） - 对集合类变量，只记录
size()和前3个元素的toString()，用Optional.ofNullable(list).map(List::size).orElse(0)防空指针 - 时间类统一转为ISO格式字符串：
Instant.now().toString()，别用new Date().toString()（时区不明确）
Log4j2 / SLF4J 日志中嵌入结构化快照数据
纯文本日志查起来反人类，但又不能每条都打完整JSON——性能扛不住。折中方案是用MDC（Mapped Diagnostic Context）塞关键字段，再配合日志模板输出。
- 在异常前一刻把变量塞进MDC：
MDC.put("user_id", String.valueOf(userId)); MDC.put("req_id", requestId); - log4j2.xml里配置
%X{user_id} %X{req_id}到PatternLayout，确保这些字段稳定出现在每条日志开头 - 不要往MDC塞大对象（如
Map或整个HttpRequest），只放简单类型字符串或数字，否则GC压力大、线程间可能污染 - 记得在请求结束时调用
MDC.clear()（尤其在Filter或Interceptor里），否则线程复用时会带出上一个请求的脏数据
Throwable.getStackTrace()不够用？得补运行时上下文
printStackTrace()只告诉你“哪里炸了”，不告诉你“炸之前数据长啥样”。要还原现场，必须主动采集。
- 在关键方法入口用
@Slf4j的log.debug("enter method, param={}", param)，但仅限调试环境开启DEBUG日志级别 - 对异步任务（如
CompletableFuture），异常可能发生在另一个线程，必须在exceptionally()或handle()里显式记录上下文，不能依赖主线程MDC - 使用
Thread.currentThread().getStackTrace()成本高，仅用于临时诊断；生产环境改用字节码增强（如Byte Buddy）在方法出口自动埋点 - JDK9+ 可考虑
StackWalker.getInstance().walk(...)替代getStackTrace()，更轻量，但注意它默认不包含本地变量表信息
为什么不该用try-with-resources自动保存快照
有人想封装一个SnapshotAutoCloseable，在close()里把变量写进文件或发到MQ——这非常危险。
立即学习“Java免费学习笔记（深入）”；
- 异常发生时JVM可能已处于不稳定状态，
close()里的IO或网络调用大概率失败甚至阻塞，拖垮整个异常处理流程 - 资源类生命周期和业务逻辑解耦，你无法保证
close()一定在异常后立刻执行（比如被finally块里的其他异常吞掉） - 快照数据需要和异常堆栈强绑定，而
try-with-resources的close()是独立执行的，时间差可能导致变量值被后续代码修改 - 真要落盘，用异步队列+内存缓冲（如Disruptor），但前提是快照数据已在
catch里序列化完毕，close()只负责投递
最易被忽略的一点：快照不是越多越好。CPU寄存器、线程栈深度、GC次数这些系统级指标，比盲目打印10个DTO字段更能指向根因。但它们没法在Java层直接读——得靠JVM参数（如-XX:+PrintGCDetails）或java.lang.management接口定时采样，和异常日志分开存储、关联分析。
