日志框架通过StackTraceElement定位代码位置而非追踪变量，利用JVM调用栈快照能力；主流框架用new Throwable()或Thread.currentThread().getStackTrace()获取堆栈，索引2/3起为业务代码。
日志框架中变量堆栈追踪，并不真去“追踪变量”，而是通过 StackTraceElement 快速定位日志语句所处的代码位置——类、方法、文件、行号。这背后不是动态监控变量，而是利用 JVM 在运行时对调用栈的快照能力。
日志中如何拿到堆栈信息
主流日志框架（如 Log4j、SLF4J + Logback）在启用 %class、%method、%line 等占位符时，会触发一次轻量级堆栈采集。常见实现方式有两种：
-
主动构造 Throwable：调用
new Throwable().getStackTrace()，不抛出异常，仅借其初始化时自动捕获当前线程堆栈的机制； -
调用 Thread API：使用
Thread.currentThread().getStackTrace()，直接读取当前执行路径的栈帧数组。
两者返回的都是 StackTraceElement[]，每个元素对应一个调用层级，但注意：索引 0 和 1 通常是日志框架内部方法，真正业务代码通常从下标 2 或 3 开始。
为什么不用异常对象的 getStackTrace()
在普通日志场景中，没有异常发生，所以不能依赖 Exception.getStackTrace()。该方法只对已抛出/捕获的 Throwable 实例有效。而日志需要的是“此刻谁在打日志”，因此必须用 new Throwable() 或 Thread.getStackTrace() 主动抓取。
- 前者兼容性更好，几乎所有 JDK 版本都支持；
- 后者更轻量，但某些精简运行环境（如 GraalVM 原生镜像）可能限制其精度；
- 二者都存在性能开销，深度嵌套调用下获取几十个栈帧会带来微秒级延迟，高吞吐日志场景需谨慎开启。
实际日志输出中的堆栈映射逻辑
以 Logback 的 %class{20}.%method(%line) 为例，它会：
一款AI工具，主要用于选择要监控的 AI 助手 → 查看 token 消耗。支持 Hermes / Claude Code / CodeX / OpenClaw，每次需手动选择，适合需要提升相关任务效率的用户。
- 先获取完整的
StackTraceElement[]数组； - 跳过日志门面和 appenders 的内部方法（一般过滤前 3–5 层）；
- 取第一个非框架类的
StackTraceElement； - 调用
element.getClassName()、element.getMethodName()、element.getLineNumber()拼接字符串。
若某行日志输出为 com.example.UserService.save(87)，说明日志语句写在 UserService.java 第 87 行的 save() 方法内——哪怕这一行只是 log.info("saving...")，也能准确定位。
性能与可维护性的权衡
开启堆栈位置日志虽便于排查，但有明确代价：
- 每次日志打印增加约 1–5 微秒 CPU 时间（取决于栈深度）；
- 生成的字符串更长，占用更多内存和磁盘 IO；
- 在异步日志（如 AsyncAppender）中，栈信息反映的是日志入队时的调用点，而非最终写入时的上下文，这点容易误判。
生产环境建议：仅在 debug 级别或特定模块开启，或用条件化策略（如错误日志强制带位置，info 日志默认关闭）。
