json.Marshal跳过自定义MarshalJSON方法，是因为方法未导出、接收者类型与传入值不匹配、签名错误，或值不可寻址导致反射无法调用；其他反射库如mapstructure也不识别该接口。
反射中 json.Marshal 为什么跳过自定义 MarshalJSON 方法？
因为 Go 的 json 包在反射路径里**优先检查接口实现而非结构体字段标签**，但前提是该类型显式实现了 json.Marshaler 接口。如果你的类型定义了 MarshalJSON 方法但没导出（首字母小写），或接收者是值而非指针（而你传的是指针），json.Marshal 就会直接忽略它，退回到默认字段反射逻辑。
常见错误现象：json.Marshal 输出空对象 {} 或字段全为零值，明明写了 MarshalJSON 却没被调用。
- 确保方法签名完全匹配：
func (t T) MarshalJSON() ([]byte, error)或func (t *T) MarshalJSON() ([]byte, error) - 接收者类型必须和你传给
json.Marshal的实际值一致：传&t就得有指针接收者，传t就得有值接收者 - 方法名、参数、返回值类型一个字符都不能错——Go 不做模糊匹配
- 如果类型嵌套在 interface{} 或 map[string]interface{} 里，反射路径可能绕过接口检查，直接序列化底层结构
自定义序列化时，encoding/json 和反射库（如 mapstructure）的优先级冲突
反射类库（比如 mapstructure.Decode）不认 json.Marshaler，它们只看字段标签、导出性、嵌套结构。这意味着：你写了 MarshalJSON 控制 JSON 输出，但用 mapstructure 把 map 解成 struct 时，它完全无视那个方法，只按字段名+类型硬映射。
使用场景：API 接收 JSON → 解码到 struct → 再转成内部 domain 对象 → 存 DB。中间某步用了非 json 包的反射工具，就容易出现字段丢失或类型错位。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
json包的序列化/反序列化走的是接口优先路径；其他反射库基本都走结构体字段反射路径 - 没有全局“序列化优先级表”，每个包各自维护自己的规则，别指望它们行为一致
- 若需统一行为，要么全用
json包（包括 decode），要么在自定义类型里把UnmarshalJSON和DecodeHook配合起来用
reflect.Value.MethodByName 查不到 MarshalJSON 的真实原因
不是方法名拼错了，也不是没导出——而是 reflect.Value 的 MethodByName **只查找导出方法，且只对能寻址的值生效**。如果你传的是不可寻址的临时值（比如函数返回的 struct 值、字面量），MethodByName("MarshalJSON") 直接返回无效值，不会报错也不会 fallback。
示例：v := reflect.ValueOf(MyStruct{}) → v.MethodByName("MarshalJSON") 是 Invalid；但 v := reflect.ValueOf(&MyStruct{}) → 先 v.Elem() 再查，才可能成功。
- 判断是否可寻址：
v.CanAddr()，不可寻址就别想调用任何方法 - 值接收者方法，要求
v.Kind() == reflect.Struct且v.CanAddr() == true；指针接收者则要求v.Kind() == reflect.Ptr - 别依赖
MethodByName做关键路径判断——先用reflect.TypeOf(t).Implements(reflect.TypeOf((*json.Marshaler)(nil)).Elem().Type())检查接口实现更稳
性能陷阱：在循环里反复用反射检查 MarshalJSON 是否存在
每次调用 reflect.TypeOf(x).MethodByName("MarshalJSON") 都触发一次方法表遍历，开销不小。高频序列化场景（如日志、metrics、gRPC 返回）下，这比直接调用接口方法慢 10–50 倍。
真正影响性能的不是反射本身，而是没做缓存——Go 的 reflect.Type 是可比较的，完全可以预热后存 map。
- 用
sync.Map缓存reflect.Type → hasMarshaler结果，键是t.Type() - 避免在 hot path 中调用
reflect.Value.Method；提前用reflect.Value.Call封装好 callable，复用 - 如果类型固定（比如只处理几种 domain struct），干脆硬编码类型 switch，比反射快一个数量级
最容易被忽略的是：很多人以为“用了反射就注定慢”，其实慢在重复反射，而不是反射调用本身。缓存 Type 和 Method 信息，性能差距能抹平八成。
