Go 的 encoding/json 包用反射辅助字段映射和值填充，但词法分析、语法解析、类型解码等核心解析工作均由自身完成，reflect 包无法替代 json.Unmarshal。
Go 的 encoding/json 包不是“用反射实现 JSON 解析”，而是**用反射辅助字段映射和值填充**；它自己完成全部词法分析、语法解析、类型解码——你无法绕过它，仅靠 reflect 包手动还原一个 JSON 字符串。
为什么不能只用 reflect 包替代 json.Unmarshal？
因为 json.Unmarshal 要做的事远不止“把 map 的 key 对上结构体字段”：
- 它得识别
"123"是数字还是字符串，再决定调field.SetInt()还是field.SetString() - 它要处理嵌套对象：
{"user":{"name":"Alice"}}→ 递归进入user字段再解析 - 它得支持
null、omitempty、-、大小写转换、时间格式（如 RFC3339）等语义 - 它还要做类型兼容性检查：比如把 JSON 字符串
"true"转成 Go 的bool，或把"2024-01-01"解析为time.Time
而 reflect.Value.Set() 只负责“赋值”，不负责“解码”。直接拿 map[string]interface{} 遍历 + Set()，遇到 "123" 往 int 字段塞，会 panic —— 它不会自动类型转换。
反射在 json.Marshal/Unmarshal 中的真实角色
它干的是“一次性建表 + 多次查表”的活，不是每次调用都现场反射：
立即学习“go语言免费学习笔记（深入）”；
- 首次对某 struct 类型调用
json.Marshal时，内部会执行typeFields()，用反射扫描所有导出字段，提取jsontag、计算内存偏移、缓存成structType映射表 - 这个表存在全局
structCache里，后续同类型序列化直接查表，跳过反射开销 - 但如果你实现了
MarshalJSON()方法，整个缓存逻辑就被绕过了——反射不再参与字段遍历，全由你代码控制
所以性能敏感场景下，首次 Marshal 稍慢是正常的；但更关键的是：**别在 MarshalJSON 里重复 parse tag**，想复用原生行为，直接对子字段调 json.Marshal 更安全。
怎么安全读取和解析 struct 的 json tag？
别手撕字符串，用 StructTag.Get("json")：
-
field.Tag.Get("json")返回完整标签内容，例如"user_name,omitempty"或"-" -
"-"时返回空字符串，表示忽略该字段 -
"name,omitempty"需用strings.SplitN(tag, ",", 2)[0]提取真实字段名，别用正则或strings.Split(tag, ",")—— 后者在含空格或转义引号时会崩 - 没写
json:tag 时也返回空字符串，此时默认用字段名小写形式（UserName→username）
常见错误是直接对 field.Tag 字符串做 strings.Contains 或正则匹配，结果在 json:"id,string" 或 json:"name,omitempty" 场景下误判。
最易被忽略的一点：反射能帮你拿到字段名和 tag，但**永远不负责 JSON 字符串的合法性校验、编码边界或流式解析**。哪怕你把所有字段都映射对了，只要原始 JSON 本身语法错误（比如少个逗号、多引号），json.Unmarshal 仍会报错——反射在这里只是配角，不是解析引擎本身。
