Golang结构体字段使用指针的设计考量

结构体字段应声明为指针当且仅当需表达可空性、延迟初始化、共享修改或避免大对象拷贝；小值类型若确定非空且无需区分零值与未设置，则优先用值类型。

什么时候该把结构体字段声明为指针

字段用指针不是为了“看起来高级”，而是明确表达「该字段可为空、可延迟初始化、或需共享修改」。如果字段类型是 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 从编译期推迟到运行时。