结构体字段应声明为指针当且仅当需表达可空性、延迟初始化、共享修改或避免大对象拷贝；小值类型若确定非空且无需区分零值与未设置，则优先用值类型。
什么时候该把结构体字段声明为指针
字段用指针不是为了“看起来高级”，而是明确表达「该字段可为空、可延迟初始化、或需共享修改」。如果字段类型是 string、int、bool 这类小值类型，又确定非空且不需区分零值与未设置，用值类型更安全、更直观。
- 需要表示“未设置/不存在”语义时（如 API 响应中可选字段），用
*string而非string，因为""和nil含义不同 - 字段指向大对象（如
[]byte超过几百字节、嵌套深的结构体）时，用指针避免每次赋值/传参都拷贝，但要注意这会增加 GC 压力 - 多个实例需共享同一底层数据（比如共用一个配置缓存、日志句柄），字段必须是指针，否则复制后各自持有一份副本
JSON 反序列化时 *string 字段为何常为空
Go 的 encoding/json 在遇到 JSON 中缺失字段或 null 值时，会把 *string 字段设为 nil；但如果字段是 string，则设为 ""。这容易让人误以为“没反序列化成功”，其实只是符合预期行为。
- 若希望缺失字段保持原值（比如结构体已初始化过），不能依赖默认反序列化，得用自定义
UnmarshalJSON方法 - API 客户端接收响应时，用
*string可靠地区分「客户端没传这个字段」和「客户端传了空字符串」 - 注意：
json:"field,omitempty"对*string仅在指针为nil时忽略字段；对string则在值为""时忽略——两者触发条件不同
方法接收者用指针时，字段指针是否必须同步调整
无关。接收者是否用指针（func (s *MyStruct) Do()）只影响结构体本身能否被修改，和其内部字段是否为指针完全解耦。字段指针的设计决策应独立于接收者类型。
- 即使接收者是值类型
func (s MyStruct) Do()，字段仍可声明为*int—— 你只是复制了指针值，它仍指向原来的整数 - 反过来，接收者用指针，字段用
int也没问题；修改字段只是改结构体副本里的那个整数，不影响其他副本 - 真正要小心的是：字段指针指向的数据生命周期是否长于结构体自身。例如字段是
*os.File，而结构体被频繁创建销毁，但文件句柄没关闭，就会泄漏
type Config struct {
TimeoutSec *int `json:"timeout_sec,omitempty"`
LogPath *string `json:"log_path,omitempty"`
}
// 反序列化时：
// { "timeout_sec": 30 } → TimeoutSec 指向 int(30)
// { "log_path": null } → LogPath == nil
// { } → TimeoutSec == nil, LogPath == nil
字段指针最易被忽略的点不在语法，而在所有权和生命周期：谁负责分配？谁负责释放？是否可能悬空？这些问题不厘清，*T 就只是把 bug 从编译期推迟到运行时。 
