MethodByName返回零值是因为方法未导出（首字母小写）、接收者类型不匹配（值类型传入却需指针接收者）或传入非指针实例；Call前必须检查IsValid()和CanCall()，否则panic。
Go 反射不能自动“发现”路由，所有动态路由注册都必须显式触发、手动校验、一次性完成；90% 的失败源于方法未导出、接收者非指针、或 reflect.Value.Call 前没检查 IsValid() 和 CanCall()。
为什么 reflect.Value.MethodByName 总返回零值
这不是反射写错了，而是 Go 的导出规则和接收者绑定机制在起作用。方法名小写、接收者是值类型、或传入的是结构体值而非指针，都会导致 MethodByName 返回无效值。
- 方法必须首字母大写（
GetUsers✅，getUsers❌） - 接收者必须是指针类型：
func (u *UserAPI) GetUsers(...)，不是func (u UserAPI) GetUsers(...) - 调用时必须传指针实例：
reflect.ValueOf(&u).MethodByName("GetUsers")，不是reflect.ValueOf(u).MethodByName("GetUsers") - 若结构体来自其他包，确保该包被空导入（
import _ "yourapp/handlers"），否则构建时会被裁剪掉
reflect.Value.Call panic：“call of reflect.Value.Call on zero Value”
这个 panic 通常不是参数传错了，而是你试图调用一个根本不可调用的 reflect.Value —— 它甚至没通过基础校验。
- 必须在
.Call()前加双重判断：if !method.IsValid() || !method.CanCall() - 签名必须严格匹配：
method.Type().NumIn() == 2且method.Type().In(1).String() == "*http.Request"（注意是*http.Request，不是http.Request） - 传参时每个
reflect.Value必须可寻址、类型可赋值：比如函数要*int，你就得传reflect.ValueOf(&x)，不能传reflect.ValueOf(x) - 别把未初始化的变量（如
var h *MyHandler且h == nil）直接丢进reflect.ValueOf
struct tag 放在哪？方法上还是结构体字段上
Go 原生不支持方法级 tag，所谓“route:"GET /users"”写在方法注释里是脆弱方案——正则解析易崩、IDE 重命名会断、go doc 不保证顺序。最稳的方式是把 tag 定义在结构体字段上。
立即学习“go语言免费学习笔记（深入）”；
- 推荐结构：
type UserAPI struct { GetUsers func(http.ResponseWriter, *http.Request) `route:"GET /api/users"` } - 字段类型必须是函数，且签名固定，便于反射统一提取和校验
- 如果坚持用方法，只能靠
go:generate + go/parser解析源码，但启动时加载成本高、不可靠，不建议用于生产 - tag 值建议扁平化：用
method:"POST" path:"/v1/order" middleware:"auth"，比嵌套 map 更轻量，strings.Split就能拆
为什么不能用 http.HandleFunc 实现真正动态路由
http.HandleFunc 是静态绑定接口，路径硬编码、无法运行时增删、http.DefaultServeMux 非并发安全——它只适合 demo，撑不起配置驱动或插件化场景。
- 真正动态的前提是绕过
http.DefaultServeMux，自己实现http.Handler - 核心逻辑：把所有合法 handler 存进
map[string]http.HandlerFunc，key 为r.Method + " " + r.URL.Path（如"POST /api/users"） - 自定义
ServeHTTP中拼 key 查表，无匹配直接返回 405，不 panic、不阻塞 - 这样新增路由只需更新 map，无需重启服务（当然，handler 本身仍需编译后加载）
最容易被忽略的一点：反射开销只在启动期，但一旦漏掉 IsValid() 校验，panic 会发生在每次请求里——而错误信息只说“zero Value”，根本看不出是哪个方法、哪行注册逻辑出了问题。上线前务必用单元测试覆盖所有 handler 的反射提取与调用路径。
