会，struct仍是值类型，赋值时拷贝指针值而非所指内存，导致共享底层数据；传参、json解码、gc、sync.pool及==比较均受此影响。
值类型字段里存 *T 会改变结构体的“可复制性”吗？
会，但不是你想的那样——struct 本身仍是值类型，赋值时仍按字节拷贝，只是拷贝的是指针值（即地址），不是它指向的堆内存。这意味着两个结构体变量可能共享同一片底层数据。
- 常见错误现象：
struct赋值后修改其中一个的指针字段所指向的内容，另一个“意外”跟着变 - 使用场景：需要节省内存（避免大对象拷贝）或允许跨实例共享状态，比如缓存、配置快照、树节点
- 参数差异：
func f(s MyStruct)传值时只拷贝指针本身（8 字节），而func f(s *MyStruct)才真正避免结构体整体拷贝 - 性能影响：小结构体里放
*T几乎无开销；但如果T很小（如int），用*int反而增加间接寻址和 GC 压力
json.Unmarshal 对含指针字段的 struct 解析行为
Go 的 json 包默认忽略 nil 指针字段的反序列化，也不会自动 new 出新对象——它只在目标字段非 nil 时写入值；若字段是 *T 且为 nil，对应 JSON 字段存在也不会被处理。
- 常见错误现象：JSON 有
"name": "foo"，但 struct 字段是Name *string且未初始化，解码后Name仍是 nil，不报错也不赋值 - 解决办法：显式初始化指针字段，或用
json.RawMessage延迟解析，或改用sql.NullString类型做语义标记 - 兼容性注意：如果 API 返回字段可能缺失，又想统一处理空值，建议字段类型用
*T+ 文档约定“nil 表示未提供”，而非依赖默认零值
GC 如何看待嵌套在值类型里的指针？
只要该值类型变量本身可达（比如在栈上被局部变量引用，或在堆上被其他活跃对象引用），其内部的 *T 就构成一条根路径，指向的 T 实例不会被回收——哪怕这个 struct 是栈分配的。
- 容易踩的坑：函数返回一个含
*T的局部struct，其中指针指向函数内 new 的对象——这没问题；但若指针指向函数内声明的局部变量（如&x），则 x 逃逸到堆，依然安全 - 性能提示：频繁创建含指针的短命结构体（如循环中
append([]S{{Field: &v}})），可能增加堆分配和 GC 频率，不如直接存值或复用对象 - 调试技巧：用
go build -gcflags="-m"看逃逸分析，确认&v是否真的逃逸，别凭直觉猜
混合内存模型下，sync.Pool 缓存含指针的 struct 安全吗？
安全，但必须确保池中对象重用前清空所有指针字段（或保证它们指向的内容仍有效）。否则上次使用的 *T 可能指向已释放/过期内存，或引发数据污染。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误：
pool.Put(&MyStruct{Data: someSlice})后，下次Get()拿到的 struct 里Data还指着旧 slice，而 slice 底层数组可能已被复用 - 实操建议：在
Put前手动置零指针字段，或实现Reset()方法统一清理；不要依赖 GC 清理池中对象 - 边界情况：如果指针指向的是全局常量或包级变量（如
&someGlobalVar），那可以跳过清理——但这种模式要格外小心生命周期
最易被忽略的一点：结构体里混用值和指针字段时，== 比较永远不等于你预期的“逻辑相等”。哪怕所有字段都一样，只要有一个 *T 指向不同地址，结果就是 false。别试图用 == 判断含指针结构体的相等性。
