StackWalker 比 Thread.currentThread().getStackTrace() 快，因其懒加载解析、跳过 JDK 内部帧，开销降至 1/5 以内；但 walk() 仍需栈快照，高频调用可能成瓶颈。
StackWalker 为什么比 Thread.currentThread().getStackTrace() 快
因为 Thread.currentThread().getStackTrace() 会强制展开全部栈帧、构建完整 StackTraceElement 数组，哪怕你只关心最上面两层；而 StackWalker 默认以懒加载方式遍历，只解析你实际访问的帧，且跳过 JDK 内部帧（如 java.base 中的反射/启动代码），开销能降到 1/5 以内。
但注意：它不是零成本——每次调用 walk() 仍需快照当前栈，频繁调用（如每毫秒一次）仍可能成为瓶颈。
如何用 StackWalker 获取当前方法的直接调用者（caller）
最常见需求是“谁调用了我”，即跳过当前方法和 StackWalker 自身调用，取第 2 层帧（索引为 1）：
String caller = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE)
.walk(s -> s.skip(2).findFirst())
.map(frame -> frame.getClassName() + "." + frame.getMethodName())
.orElse("unknown");
关键点：
-
StackWalker.Option.RETAIN_CLASS_REFERENCE是必须的，否则frame.getDeclaringClass()返回 null，连类名都拿不到 -
skip(2)：跳过当前方法（getCurrentCaller()）、walk()的 lambda 匿名类，定位到真实调用者 - 不用
limit(1)，避免提前终止流导致后续帧未被跳过 - 如果要获取行号，确保编译时未加
-g:none，否则frame.getLineNumber()恒为 -1
StackWalker 在 Lambda 和匿名类中的行为差异
当调用链含 Lambda 时，frame.getClassName() 返回的是合成类名（如 MyService$$Lambda$123/0x00000008000a0000），frame.getMethodName() 是 apply 或 run，无法还原原始 lambda 位置。
此时不能依赖类/方法名做判断，建议：
- 用
frame.getFileName()+frame.getLineNumber()定位源码位置（更稳定） - 若需区分不同 lambda，可结合
frame.getDeclaringClass()的getSimpleName()粗略判断上下文类 - 避免在性能敏感路径中对 lambda 帧做字符串匹配，合成类名无规范，JVM 可能变更生成策略
为什么 getCallerClass() 不推荐用于生产环境
JDK 9+ 提供了 StackWalker.getCallerClass() 这个快捷方法，但它有严重限制：
- 仅返回调用者的
Class对象，不提供方法名、行号等上下文 - 在启用安全管理器（SecurityManager）或某些字节码增强框架（如 Byte Buddy、Spring AOP）下可能抛
UnsupportedOperationException - 它底层仍走
StackWalker，但封装太死，无法跳过中间代理帧（比如 CGLIB 生成的$$EnhancerBySpringCGLIB$$类） - 真正需要“精准”时，宁可用带
skip()和filter()的完整 walk 流
低开销和精准之间本就存在权衡——StackWalker 的设计哲学是“按需解析”，一旦你开始过滤、跳过、多次 findFirst()，就要自己承担逻辑复杂度。别为了省几纳秒，把调用栈解析写成状态机。
