匿名结构体适合临时组合数据、json解析未知响应、测试构造输入等一次性场景；不该在多函数传递、需方法或类型断言时使用，此时应定义具名结构体。
匿名结构体什么时候该用，什么时候不该用
匿名结构体适合临时组合数据、避免定义冗余类型，但不能被复用、无法实现方法、不能作为接口实现者。它本质是“一次性快照”，不是设计模式里的实体。
- 适合场景：
json.Unmarshal解析未知结构的响应体、测试中构造临时输入、函数内局部数据聚合 - 危险信号：在多个函数间传递
Struct{...}、想给它加方法、需要做类型断言或反射判断——这时该定义具名结构体了 - 注意：
map[String]struct{ Name string }比map[string]User更重（每次都要重复字段定义），编译器无法复用底层内存布局
嵌入字段不是继承，别当成“父类”来用
go 的嵌入（embedding）只是字段提升（field promotion）的语法糖，不带任何运行时多态或方法重写机制。调用 child.Method() 看起来像继承，实际只是编译器自动补全了 child.embedded.Method()。
- 冲突处理：如果两个嵌入字段都有
Print()方法，child.print()会编译报错，必须显式写成child.A.Print()或child.B.Print() - 零值陷阱：嵌入一个指针字段（如
*http.Client）后，未初始化就调用其方法会 panic，而嵌入值类型（如sync.Mutex）则天然安全 - 导出限制：只有导出的字段（首字母大写）才会被提升；
type inner struct{ x int }嵌入后，x不可直接访问
嵌入 Interface 和嵌入 struct 的行为差异
嵌入 interface{} 只提供方法集合并，不带任何字段或实现；嵌入 struct{} 是把字段和方法都拉进来。这是最常被混淆的一点。
- 嵌入
io.Reader：仅让当前类型“拥有”Read()方法签名，具体实现还得自己写或靠其他嵌入提供 - 嵌入
bytes.Buffer：既获得Read()/Write()方法，也获得底层buf []byte字段，可直接读写内部状态 - 典型误用：嵌入
Error接口试图“继承错误能力”——没用，error是接口，嵌入它不会自动让类型满足error，你还得实现Error() string
匿名结构体 + 嵌入字段组合时的字段冲突与 JSON 序列化问题
当匿名结构体里嵌入另一个结构体，且两者有同名字段时，JSON 标签（json:"..."）不会自动合并或覆盖，而是以字段声明顺序为准，容易漏序列化或产生歧义。
立即学习“go语言免费学习笔记（深入）”；
- 示例：
struct{ A string; struct{ A int } }中，外层A会被序列化，内层A被忽略（即使加了json:"a"） - 解决办法：显式重命名嵌入字段，比如
Inner struct{ A int } `json:"inner"`，或干脆不用匿名，改用具名字段 - 注意：
json:",inline"标签只对嵌入的 struct 类型生效，对匿名结构体本身无效；它会让嵌入字段“扁平化”到外层对象中，但同名字段仍会覆盖
匿名结构体和嵌入字段都不是黑魔法，它们的价值在于减少样板代码，而不是掩盖设计模糊。真正容易被忽略的是：一旦开始嵌入指针类型或多个同名字段的结构体，调试时看 fmt.printf("%+v", v) 输出会变得极难对应到源码字段路径。