getStackTrace() 返回当前线程的调用栈快照，即从当前执行点回溯的方法调用链，不包含 native 方法和被 JIT 内联的方法，也不反映对象创建路径或协程挂起上下文。
getStackTrace() 返回的是谁的调用栈？
它返回的是当前线程（Thread.currentThread()）正在执行的方法调用链，也就是「从当前点往回看，是谁一层层调用到这里的」。注意：不是某个对象的创建路径，也不是异常抛出时的完整上下文，只是快照式的一次栈帧快照。
常见误用是以为它能追溯到某行 new X() 的位置——其实不能，除非那行刚好在当前调用链上。
- 只包含 Java 方法（
java.lang.*、sun.*等内部类默认被截断或省略，取决于 JVM 参数） - 不包含 native 方法调用（如
Object.wait()后面的底层阻塞） - 如果在
finally或catch块里调用，栈顶是当前块所在方法，不是异常源头
怎么过滤掉无关栈帧、只留业务代码？
默认输出包含大量 JDK 内部调用（比如 java.lang.Thread.getStackTrace() 自身、java.util.concurrent 调度器等），直接打印会淹没关键路径。得手动跳过这些“噪声”。
推荐做法是：从索引 2 或 3 开始遍历（跳过 getStackTrace() 和它的直接调用者），再按包名过滤：
StackTraceElement[] stack = Thread.currentThread().getStackTrace(); for (int i = 2; i
- 索引 0 是
getStackTrace()自身；索引 1 通常是你的日志封装方法；业务起点一般在索引 2～4 之间，需实测确认 - 避免硬写
i 这种截断逻辑——深度嵌套时会漏掉上层业务调用 - 若项目用了字节码增强（如 Spring AOP、MyBatis 插件），栈中会出现
$$EnhancerBySpringCGLIB$$类，这类也建议保留，它们代表实际触发点
在日志里加调用路径，但别拖慢性能
频繁调用 getStackTrace() 开销不小：每次都要复制整个栈帧数组，且触发 JVM 栈遍历。线上高频场景（如每请求都打）可能让吞吐下降 5%～20%。
- 只在 debug 日志级别启用，生产环境默认关闭（用
if (log.isDebugEnabled()) { ... }包裹） - 不要在循环体或热点方法内直接调用；可提取为工具方法 + 条件开关
- 替代方案：用
Throwable.fillInStackTrace()配合getStackTrace()更轻量（不构造完整异常对象），但语义稍弱 - Logback / Log4j2 支持
%class{1}.%method:%line占位符，但那是编译期静态信息，无法反映动态调用链；真要追踪路径，还是得靠运行时栈
为什么有时候看不到预期的方法？
最常见原因是 JIT 编译优化：当某个方法被频繁调用，HotSpot 可能将其内联（inlining），导致该方法不会出现在栈中。你看到的是内联后的“合并版”调用路径。
- 可通过启动参数
-XX:+PrintInlining -XX:+UnlockDiagnosticVMOptions观察哪些方法被内联了 - 临时禁用内联：加
-XX:CompileCommand=exclude,com/example/YourClass::yourMethod - 另一个干扰源是 Lambda 表达式和方法引用——它们会被编译成合成方法（如
lambda$doWork$0），名字不直观，需结合上下文类名判断 - 协程（如 Kotlin Coroutines、Quasar）或虚拟线程（Loom）下，
getStackTrace()仍只返回 OS 线程级栈，不体现协程挂起点；此时需用对应框架的调试 API
调用栈是动态快照，不是全息记录；它反映的是“此刻控制流在哪里”，而不是“这个对象是怎么诞生的”。想靠它定位初始化源头，往往得配合断点、条件日志或字节码分析才可靠。
