go反射无法获取函数参数名，因编译后二进制不保留形参标识符；可通过结构体封装、源码解析或生成代码等方式替代，但 runtime.caller 等“猜测”方式不可靠。
Go 反射拿不到函数参数名，这是语言设计决定的
Go 的 reflect 包在运行时能拿到函数签名里的类型、数量、是否是变参，但Func.Type().In(i) 返回的只是类型，没有参数名。编译后的二进制里压根不保留形参标识符——不是反射没做全，是根本没存。
这和 Python、Java 不同，Go 为减少元数据体积和启动开销，主动舍弃了这一信息。你查 runtime.FuncForPC 或 debug.ReadBuildInfo 也找不到它。
想“模拟”获取参数名？只能靠源码解析或结构体标签
真要让函数参数可被外部识别，得提前约定方式，而不是指望运行时自动吐出来：
- 用结构体封装参数，字段名天然可反射：
reflect.TypeOf(MyStruct{}).Field(i).Name - 给函数绑定自定义注释（如
// @param name string "user ID"），再用go/doc包解析源码文件 - 手动维护映射：写个
map[reflect.Value][]string，把reflect.ValueOf(fn)和预设的参数名列表挂上
注意：源码解析依赖 .go 文件存在且路径可访问，CI 环境或部署后二进制里就失效了。
立即学习“go语言免费学习笔记（深入）”；
别误用 runtime.Caller 去“猜”参数名
有人试过在函数开头调 runtime.Caller(1) 拿调用点源码行，再正则提取 fn(a, b, c) 里的 abc —— 这非常脆弱：
- 一行多调用、换行调用、变量解构（
fn(x...)）都会崩 -
go build -ldflags="-s -w" 会删掉行号信息，
Caller返回空文件名 - 内联优化后，
Caller可能跳到完全无关的位置
这不是权宜之计，是典型“看起来能跑，上线就错”的陷阱。
真正需要参数名的场景，通常该换设计
比如写 HTTP handler、RPC 方法、CLI 命令，与其纠结怎么从 func(string, int, bool) 提取名字，不如：
- 统一用结构体入参：
func(ctx context.Context, req *CreateUserReq) error - 用
map[string]any+ 显式校验，名字由调用方传入（适合配置驱动逻辑） - 生成代码：用
go:generate+ast包在构建时扫描函数并生成参数名常量
Go 的反射本就不鼓励“动态发现”，硬拧参数名，往往说明接口契约不够清晰——名字不该藏在运行时，而该出现在类型定义或文档里。
