根本原因是Go中嵌套结构体字段若为值类型（如int、string或非指针结构体），每次访问都会触发复制，即使方法使用指针接收者，对s.Inner.Value的修改也仅作用于该副本；只有字段本身是指针（如*Inner）或显式取地址（&s.Inner）才能修改原始内存。
为什么嵌套结构体字段改不了，明明用了指针接收者？
根本原因在于：Go 中结构体字段赋值是值拷贝，即使方法用指针接收者，struct.field 如果本身是值类型（如 int、string 或非指针结构体），对它的修改只作用于该字段的副本；只有字段本身是指针（比如 *Inner）或你显式取地址（&s.field），才能穿透到深层原始内存。
常见错误现象：s.Inner.Value = 42 看似改了，但调用后原结构体没变——大概率因为 Inner 是值字段，每次访问 s.Inner 都触发一次复制。
- 确认嵌套字段是否为指针类型：用
fmt.Printf("%T", s.Inner)检查，输出main.Inner表示值类型，*main.Inner才是真正可修改的指针 - 如果
Inner是值类型，必须用&s.Inner获取其地址再修改内部字段，否则无效 - 方法接收者用
*Outer只保证s自身可改，不自动“递归升级”所有嵌套字段为指针
怎么安全地修改三层深的 Outer.Nested.Config.Timeout？
假设结构体定义如下：
type Config struct { Timeout int }
type Nested struct { Config Config }
type Outer struct { Nested Nested }
此时 Nested.Config 是值类型，直接写 s.Nested.Config.Timeout = 10 不会生效。正确做法是让中间层也支持地址访问：
立即学习“go语言免费学习笔记（深入）”；
- 把
Nested.Config改成*Config字段（推荐，语义清晰且一次分配） - 或在方法内用
&s.Nested.Config显式取地址：configPtr := &s.Nested.Config; configPtr.Timeout = 10 - 若不能改结构体定义（如第三方库），只能先解包再赋回：
cfg := s.Nested.Config; cfg.Timeout = 10; s.Nested.Config = cfg—— 这种写法实际是覆盖整个Config值，不是“修改”，且不适用于大结构体（性能差）
json.Unmarshal 后嵌套字段仍是只读？检查指针链是否断裂
从 JSON 解析出来的结构体，如果字段声明为值类型，json.Unmarshal 默认会新建值并赋给字段，不会复用原有地址。这会导致你以为传入的是指针，实际深层字段早已脱离原始变量生命周期。
- 确保结构体字段标签和类型匹配：例如想让
Config被解析为指针，字段必须声明为Config *Config `json:"config"` - 使用
json.RawMessage延迟解析，手动控制指针分配时机 - 调试时打印字段地址：
fmt.Printf("addr: %p", &s.Nested.Config)，多次调用看是否变化；若地址变，说明被重新分配过
性能与可维护性权衡：什么时候该用指针字段而不是值字段？
嵌套结构体中频繁修改深层字段，又不想每次都写 &s.A.B.C，最省心的方式是在设计阶段就把可变字段设为指针。但这不是无代价的：
- 指针字段增加 nil 判断负担，每次访问前需检查：
if s.Nested != nil && s.Nested.Config != nil - GC 压力略增（小对象影响可忽略，但高频创建/销毁要注意）
- 序列化行为改变：nil 指针字段默认被
json.Marshal忽略，而零值字段会输出"timeout": 0 - 如果字段只读居多、写少，值类型 + 显式取地址更轻量；反之，高写频场景优先指针字段
最容易被忽略的一点：嵌套层级越深，字段是否为指针就越难肉眼识别——别依赖记忆，用 go vet 或 IDE 的类型提示实时确认 s.X.Y.Z 的真实类型。
