MethodBase.GetCurrentMethod() 是获取当前函数名最轻量可靠的方式，不依赖 PDB 或调试符号，Release 模式下仍准确有效；返回 MethodBase 可提取 Name 和 DeclaringType.Name 组成“类.方法”格式，静态/实例方法均适用，泛型名需手动截断。
用 MethodBase.GetCurrentMethod() 获取当前函数名最直接
多数时候你要的只是函数名字符串，MethodBase.GetCurrentMethod() 是最轻量、最可靠的方式。它不依赖调试符号或 PDB 文件，运行时就能拿到，连 Release 模式下也稳。
常见错误是误用 StackTrace 去解析堆栈帧——既慢又容易在内联优化后失效，还可能因异常捕获位置偏移而取错函数。
-
MethodBase.GetCurrentMethod().Name返回纯函数名（如"DoWork"） -
MethodBase.GetCurrentMethod().DeclaringType?.Name补上类名（如"Worker"），组合起来就是"Worker.DoWork" - 注意：静态方法和实例方法都适用；泛型方法会带签名（如
"Process<int>"），若只需原始名称，得手动截断<之前部分
为什么不用 StackTrace 或 CallerMemberName？
StackTrace 看似灵活，但实际踩坑多：JIT 内联后帧可能消失，Release 编译默认开启内联，GetFrame(1) 很可能指向调用方而非当前函数；而且构造 StackTrace 对象有明显性能开销，不适合高频日志场景。
CallerMemberName 是编译器特性，必须加 [CallerMemberName] string memberName = "" 参数，本质是“让调用方帮你传名字”，不是运行时反射——这意味着它不能用于间接调用（比如通过委托、事件、反射 invoke 的场景），也不适用于你无法修改函数签名的地方。
- 需要日志埋点且函数签名已固定？用
MethodBase.GetCurrentMethod() - 能改函数参数、且只关心直接调用者？
[CallerMemberName]更快更干净 - 想查调用链？别靠函数名拼，该用
DiagnosticSource或Activity
Release 模式下 MethodBase.GetCurrentMethod() 还准不准？
准。它不依赖 PDB 或调试信息，也不受内联影响——因为 JIT 不会把「获取当前方法元数据」这个操作给内联掉。哪怕整个函数被内联进上层，只要执行流还在那个方法体里，GetCurrentMethod() 就返回那个方法的 MethodBase。
唯一例外是异步状态机生成的方法（比如 MoveNext），这时你拿到的是编译器生成的 MoveNext，不是原始 async 方法名。如果必须拿到原始名，得结合 AsyncStateMachineAttribute 反射查找，但绝大多数日志/诊断场景不需要这么深。
- 普通同步方法：放心用，Release 和 Debug 行为一致
- async 方法：返回的是
"MoveNext"，不是"LoadDataAsync"；如需原始名，建议在 async 方法入口手动存到局部变量 - IL 重写（如 Fody）可能干扰，但那是少数极端情况
一个够用的工具函数长什么样？
别每次重复写三行，封装成静态方法，兼顾可读性和健壮性：
public static string GetCurrentMethodName()
{
var method = MethodBase.GetCurrentMethod();
return method?.DeclaringType switch
{
null => method.Name,
_ => $"{method.DeclaringType.Name}.{method.Name}"
};
}
这个版本处理了 DeclaringType 为 null 的边界（比如模块初始化器或某些动态方法），也避免了空引用异常。不需要泛型擦除或全名（FullName 太长），也不引入 System.Diagnostics 额外依赖。
真要兼容 async 场景？那就得额外检查 AsyncStateMachineAttribute，但那已经不是“获取当前函数名”的本意了——那是“还原语义上的入口点”，属于另一层抽象。
