应使用 Thread.currentThread().getStackTrace()[2] 获取当前方法名，索引2才是真实调用方；Android需判空，Java9+推荐StackWalker并传RETAIN_CLASS_REFERENCE选项。
怎么用 StackTraceElement 拿到当前方法名
直接靠 Thread.currentThread().getStackTrace() 获取栈帧，取索引为 2 的元素（索引 0 是 getStackTrace 自身，1 是你封装的工具方法，2 才是调用方的真实方法）。别信网上抄来就用索引 1 的代码——那在某些 JVM 实现或优化下会错。
实操建议：
- 写成工具方法时，固定用
Thread.currentThread().getStackTrace()[2]，别依赖new Throwable().getStackTrace()，后者开销略大且可能被 JIT 优化掉部分栈帧 - 如果在
static工具方法里封装，记得把索引 +1：调用栈深度会多一层，此时真实业务方法通常在索引 3 - Android 上 Dalvik/ART 对栈帧裁剪更激进，
getStackTrace()可能返回空数组或长度不足，务必加length判断
getMethodName() 返回空或乱码的常见原因
不是所有栈帧都包含完整方法信息。JVM 在内联、逃逸分析或 AOT 编译后，可能抹掉符号表，导致 StackTraceElement.getMethodName() 返回 "<unknown>"</unknown> 或空字符串。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 在
lambda表达式里调用，返回的是合成方法名如"lambda$doSomething$0"，不是原始方法名 - 使用 Lombok 的
@SneakyThrows或@Cleanup，可能插入桥接方法，干扰栈帧定位 - 启用
-XX:+OmitStackTraceInFastThrow（默认开启）时，重复异常的栈帧会被省略，但不影响正常getStackTrace()调用
比 StackTraceElement 更轻量的替代方案
如果只要方法名，不强求“绝对准确”，可以考虑 SecurityManager（Java 8 及以前）或 StackWalker（Java 9+），后者性能更好、可控性更强。
实操建议：
- Java 9+ 推荐用
StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE).walk(s -> s.skip(1).findFirst().map(StackWalker.StackFrame::getMethodName).orElse("unknown")) -
StackWalker默认不保留类引用，要获取方法名必须传StackWalker.Option.RETAIN_CLASS_REFERENCE，否则getMethodName()返回null - 别在高频循环里反复创建
StackWalker实例，复用单例更稳妥；它线程安全，但构造有开销
为什么生产环境慎用栈信息获取
每次调用 getStackTrace() 或 StackWalker.walk() 都要遍历当前线程栈，触发栈快照采集，对 GC 和 CPU 都有可测量影响。压测中见过单次调用增加 0.3ms 延迟，QPS 过万时直接拖垮 RT。
使用场景限制：
- 只应在调试、日志埋点（非每请求）、监控采样（如 1% 请求）中使用
- 禁止在
toString()、equals()、序列化器或 NettyChannelHandler的核心路径里调用 - 若必须上线，优先用编译期注解（如 AspectJ）在字节码层面注入方法名，运行时零开销
最常被忽略的一点：IDE 调试器本身就会频繁触发栈采集，开着断点跑压测，结果根本不能反映真实性能。
