Throwable的printStackTrace()输出栈轨迹的本质是：先在构造时通过native的fillInStackTrace()采集调用链并存入stackTrace数组，再由printStackTrace()遍历该数组格式化输出。
Throwable 的 printStackTrace() 输出的栈轨迹（stack trace），本质是其内部通过填充（fillInStackTrace）和遍历（getStackTrace）两个核心步骤完成的。理解这个过程，关键在于读懂 Throwable 构造器中对 fillInStackTrace() 的调用，以及 StackTraceElement[] 数组的生成逻辑。
fillInStackTrace 是栈信息的“快照捕获点”
fillInStackTrace() 是一个 native 方法（JVM 实现），它在异常对象创建时被自动调用（除非显式禁用）。它的作用是在当前线程执行位置，**立即采集从当前方法到最外层调用者（如 main）的完整调用链**，并将其转换为 StackTraceElement[] 数组，存入 backtrace 字段（JDK 8 及以前）或 stackTrace 字段（JDK 9+ 模块化后调整）。
- 该采集发生在构造器中（如
new RuntimeException()），不是在打印时才收集 —— 所以即使你稍后才调用printStackTrace()，看到的仍是“抛出时刻”的调用栈。 - 若手动传入
null或调用setStackTrace(new StackTraceElement[0])，可清空原始栈；但一旦清空，原生采集信息即丢失，无法恢复。 - 子类重写
fillInStackTrace()（返回this）可跳过采集（常用于性能敏感的自定义异常，如 Netty 的UnsupportedOperationException优化）。
StackTraceElement 数组由 JVM 填充，非 Java 层构建
StackTraceElement 是不可变的普通类，但它的实例**不由 Java 代码 new 出来，而是由 JVM 在 fillInStackTrace 的 native 实现中直接构造并填充字段**（如 declaringClass、methodName、fileName、lineNumber）。源码中你看不到循环 new，只看到：
private transient volatile Object backtrace;private StackTraceElement[] stackTrace = UNASSIGNED_STACK;
其中 UNASSIGNED_STACK 是一个标记数组，表示尚未填充；真正填充动作发生在 native 层，Java 层仅提供访问入口（getStackTrace()）。
printStackTrace() 本质是格式化输出已采集的数组
printStackTrace() 并不重新采集栈，而是：
- 调用
getOurStackTrace()（内部触发 lazy 初始化：若stackTrace == UNASSIGNED_STACK，则尝试从backtrace解析；否则直接返回缓存数组）； - 遍历
StackTraceElement[]，逐行拼接className.methodName(fileName:lineNumber)； - 对 cause 异常递归调用（带
Caused by:前缀），形成嵌套栈结构。
因此，修改 stackTrace 数组内容（如过滤掉某些帧）会直接影响所有后续打印 —— 这也是日志框架（如 Logback）做栈剪裁的基础。
调试建议：用断点 + 反编译验证采集时机
想亲眼确认采集发生点：
- 在
Throwable构造器第一行（fillInStackTrace()调用处）打断点，运行时观察backtrace字段是否已非 null； - 用
javap -v Throwable查看fillInStackTrace确实标记为native； - 对比
new Exception().getStackTrace().length和Thread.currentThread().getStackTrace().length，前者通常少 1–2 帧（因封装在 Throwable 构造器内）。
