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，或把 "2025-01-01" 解析为 time.Time

而 reflect.Value.Set() 只负责“赋值”，不负责“解码”。直接拿 map[string]interface{} 遍历 + Set()，遇到 "123" 往 int 字段塞，会 panic —— 它不会自动类型转换。

反射在 json.Marshal/Unmarshal 中的真实角色

它干的是“一次性建表 + 多次查表”的活，不是每次调用都现场反射：

• 首次对某 struct 类型调用 json.Marshal 时，内部会执行 typeFields()，用反射扫描所有导出字段，提取 json tag、计算内存偏移、缓存成 structType 映射表
• 这个表存在全局 structCache 里，后续同类型序列化直接查表，跳过反射开销
• 但如果你实现了 MarshalJ

  

  SON() 方法，整个缓存逻辑就被绕过了——反射不再参与字段遍历，全由你代码控制

所以性能敏感场景下，首次 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 仍会报错——反射在这里只是配角，不是解析引擎本身。