Go框架仅在初始化时使用反射扫描结构体或解析函数签名，之后缓存结果；请求处理全程用预编译函数值，无需反射调用。
Go 的反射不是框架的“魔法”，而是把类型信息和运行时行为显式暴露出来的一种手段；绝大多数 Web 框架只在初始化阶段用 reflect 做一次结构体字段扫描或函数签名解析，之后就缓存结果、避免重复反射 —— 频繁反射会直接拖垮性能。
为什么 Gin/echo/fasthttp 不在每次 HTTP 请求里用 reflect.Value.Call
框架路由匹配后调用 handler，这个 handler 早已是编译期确定的函数值（func(c *gin.Context)），根本不需要反射调用。反射只出现在你写 engine.POST("/user", createUser) 这类注册逻辑中：
- 检查
createUser函数参数是否含*gin.Context或自定义上下文类型 - 提取结构体字段标签（如
json:"name" binding:"required"）用于绑定请求体 - 生成中间件链时，把带
MiddlewareFunc类型的函数包装成标准中间件接口
这些动作在 engine.Run() 前完成，结果被缓存进路由树节点或 handler 元数据里。
reflect.StructTag 解析常见误用：没跳过空格、忽略键大小写
结构体标签本质是字符串，structTag.Get("json") 返回的是原始值（如 "name,omitempty"），不是解析后的 map。很多人直接拿它做字段名映射，却忘了：
立即学习“go语言免费学习笔记（深入）”；
-
json标签值里可能有空格：`json:" user_name "`→strings.TrimSpace必须手动加 -
标准库
encoding/json对键名大小写敏感，但某些框架（如 gin binding）默认转小写匹配，导致`json:"UserName"`绑定失败 - 多个标签共存时（如
json:"name" binding:"required"），必须用structTag.Lookup而非Get，否则取不到第二个标签
正确做法是用 structTag.Get("json") 后，交给 strings.SplitN(..., `"`, 2) 或更稳妥的 structtag 第三方库解析。
用 reflect.Value.Convert 强转 interface{} 时 panic 的真实原因
常见场景：从 URL 查询参数拿到 string，想转成 int64 存入结构体字段。有人写：
v := reflect.ValueOf(&user).Elem().FieldByName("ID")
v = v.Convert(reflect.TypeOf(int64(0)).Type()) // panic: cannot convert string to int64
这行代码错在：Convert 只支持底层类型一致的转换（如 int ↔ int32），不支持跨类型解析。真正该做的是：
- 先判断目标字段类型（
v.Kind() == reflect.Int64） - 再用
strconv.ParseInt解析原始字符串 - 最后用
v.SetInt(parsed)赋值（注意：字段必须可寻址、可导出）
所有 Web 框架的 binding 逻辑都绕不开这一步 —— 反射只是调度器，真正的类型转换永远靠 strconv、time.Parse 等具体解析函数。
最易被忽略的一点：反射对象一旦来自未导出字段（首字母小写）、或通过非指针传入结构体，CanAddr() 和 CanSet() 就会返回 false，后续任何赋值操作都静默失败或 panic。调试时别只盯错误栈，先打一行 fmt.Printf("can set: %v\n", v.CanSet())。
