json.unmarshal 已内置反射实现，无需手动重写；只需传地址、字段导出、tag 正确；常见错误源于地址未传、字段未导出或嵌套结构体字段未导出；动态键名必须用 map[string]t；真正需手写反射的场景极少，仅限完全不可控且需类型化解析的 json。
json.Unmarshal 已经用反射了，你通常不需要自己写
Go 的 json.Unmarshal 内部早已通过 reflect 实现字段查找、类型匹配和值赋值。你只需保证三件事：传入变量地址（&v）、结构体字段首字母大写（导出）、json tag 拼写正确。手写反射去“替代”它，就像用螺丝刀拧开已封装好的电源适配器——费力且没必要。
常见错误现象：json: cannot unmarshal object into Go value of type string 或字段全为零值，往往不是反射没写对，而是没传地址、字段未导出，或嵌套结构体里某一层字段没导出导致静默跳过。
- 字段名含连字符（如
user-id）时，tag 必须写成json:"user-id"，但结构体字段名仍得是合法标识符（如UserID） -
string修饰符（如json:"count,string"）只对数字/布尔类型生效，对字符串字段加这个没用 - 嵌套 map 或 slice 里的元素类型必须明确；若用
[]interface{}接收数字数组，后续无法直接转[]int，得逐个断言
动态键名必须用 map[string]T，不是 []T
当 JSON 中的 key 是运行时才知的 ID（如 "instances": { "28253266": { ... }, "1d774b49": { ... } }），结构体字段必须声明为 map[string]struct{...}。误写成 []struct{...} 是最常踩的坑——JSON 解析器会直接报错或静默失败，因为对象（object）和数组（array）在语法上根本不同。
实操要点：
- key 类型固定用
string，哪怕原始 JSON key 是数字（如"123"），Go 的json包也只支持字符串 key 的 map - value 类型可以是具体 struct，也可以是
json.RawMessage延迟解析，避免提前 panic - 如果 key 不合法（如以数字开头或含点号），需预处理标准化（如加前缀
key_123），否则reflect.StructOf构建结构体时会 panic
真正需要手写反射的场景：字段名/类型都未知
只有当你面对的是完全不可控的 JSON（比如用户上传的配置片段、第三方 webhook 的任意 custom_fields），且必须转成带类型信息的结构体（而非 map[string]interface{}）时，才需介入反射。核心工具是 reflect.StructOf（Go 1.15+）。
关键限制和注意点：
-
reflect.StructOf接收的reflect.StructField列表中，Name必须是合法 Go 标识符，不能是原始 JSON key；需做映射转换 - 嵌套对象不能递归调用
StructOf一次搞定——要先解析子 JSON 得到字段描述，再构造子类型，最后作为Type字段塞进父级StructField - 数字类型歧义：JSON 中的
123默认被json包解析为float64；若想按业务规则推断为int（如字段名含"id"），得在反射赋值前手动检查并转换
别指望反射还原 struct tag 里的 default 值
json tag 中的 default:"xxx" 是非标准扩展，encoding/json 完全不识别。反射本身也无法从 tag 提取该值并自动填充缺失字段。如果你依赖默认值，必须在 UnmarshalJSON 方法里手动实现，或在反射赋值后遍历字段补缺。
更现实的做法：
- 用
json.RawMessage暂存未解析字段，在后续逻辑中按需解析 - 对关键字段做显式零值检查（如
if v.Name == ""），再设默认值 - 避免在反射层过度封装；复杂校验和默认逻辑，放在业务层比塞进通用反射函数里更清晰、易测
map[string]interface{} + 显式字段提取，或为高频结构定义固定 struct，反而更稳。真正值得动反射的地方，是那些绕不开的、重复出现的动态映射模式——而不是每次遇到新 JSON 都想着“我来手撸一个通用解析器”。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
