本文深入解析 Go 语言中调用指针接收器方法时的隐式取址规则，阐明为何对非指针字段（如 json.RawMessage）的结构体取址后仍能触发 MarshalJSON，并结合内存可寻址性原理给出清晰示例与实践建议。
本文深入解析 go 语言中调用指针接收器方法时的隐式取址规则，阐明为何对非指针字段（如 `json.rawmessage`）的结构体取址后仍能触发 `marshaljson`，并结合内存可寻址性原理给出清晰示例与实践建议。
在 Go 的 JSON 编码过程中，json.RawMessage 类型定义了指针接收器方法 func (m *RawMessage) MarshalJSON() ([]byte, error)。这意味着：*只有 `json.RawMessage类型的值才能直接调用该方法**。但实际使用中，我们常发现即使字段是值类型（如Foo json.RawMessage），只要整个结构体是取址的（如&struct{ Foo json.RawMessage }{...}），json.Encoder.Encode仍能正确调用MarshalJSON` —— 这背后正是 Go 编译器对“可寻址值（addressable value）”的智能处理。
核心机制：可寻址性触发隐式取址
Go 规范明确规定：当一个值是可寻址的（即有明确内存地址，如变量、结构体字段、切片元素等），且其方法集不包含某指针接收器方法时，编译器会自动对其取址（&v），再调用该方法。这并非语法糖，而是语言层面对值语义与指针语义统一调度的关键设计。
以问题中的第三种情况为例：
_ = enc.Encode(&struct{ Foo json.RawMessage }{foo})
- &struct{...} 创建了一个可寻址的匿名结构体变量；
- 其字段 Foo 作为该结构体的组成部分，天然具备可寻址性（即 &s.Foo 合法）；
- 当 json 包内部对 s.Foo 调用 MarshalJSON 时，发现 json.RawMessage 值本身无此方法（因方法接收器为 *RawMessage），但 s.Foo 可寻址 → 编译器自动转换为 (&s.Foo).MarshalJSON()；
- 因此成功序列化为 {"zoo":123}，而非 Base64 编码的原始字节串。
对比验证：三种场景的行为差异
| 表达式 | 结构体字段类型 | 是否取址整个结构体 | MarshalJSON 是否被调用 | 输出结果 |
|---|---|---|---|---|
| struct{ Foo *json.RawMessage }{&foo} | *json.RawMessage | 否（值本身为指针） | ✅ 直接调用 | {"Foo":{"zoo":123}} |
| struct{ Foo json.RawMessage }{foo} | json.RawMessage | 否（结构体不可寻址） | ❌ 退回到默认编码 | {"Foo":"eyAiem9vIjogMTIzIH0="} |
| &struct{ Foo json.RawMessage }{foo} | json.RawMessage | ✅（结构体取址 → 字段可寻址） | ✅ 隐式取址后调用 | {"Foo":{"zoo":123}} |
? 关键提示：是否“可寻址”，取决于值是否绑定到具名变量或嵌套于可寻址容器中，而非是否显式写了 &。临时复合字面量（如 struct{...}{}）本身不可寻址；但 &struct{...}{} 创建的是可寻址变量。
实践建议与注意事项
- ✅ 安全使用：若自定义类型实现了指针接收器的 MarshalJSON/UnmarshalJSON，应确保其字段在 JSON 编码路径中始终处于可寻址上下文（如作为结构体字段并传入 &v，或声明为局部变量后再取址）。
- ⚠️ 避免陷阱：切勿依赖不可寻址值（如函数返回的 struct 字面量、map 中的值拷贝）触发指针接收器方法——此时将静默回退至默认编码逻辑，易引发数据格式错误。
- ? 调试技巧：可通过 fmt.Printf("%p", &v) 验证值是否可寻址；或借助 reflect.Value.CanAddr() 在运行时动态判断（注意：reflect.ValueOf(v).CanAddr() 返回 true 即表示可寻址）。
理解这一机制，不仅有助于正确使用 json.RawMessage，更能深化对 Go 方法集、接收器语义及内存模型的认知——它体现了 Go “显式优于隐式”哲学下的精妙平衡：隐式取址仅发生在严格可证明安全的可寻址场景中，既提升开发效率，又不牺牲可控性与可预测性。
