结构体里存指针真的能减小内存占用吗
能，但只在特定场景下有效——关键看字段是否常为零值或是否需要共享。go 中结构体大小由字段类型和对齐规则决定，int 占 8 字节（64 位系统），而 *int 也是 8 字节；单个指针未必省空间，但若字段常为 nil（比如可选配置、延迟加载字段），用指针可避免为大量零值分配内存。
常见误判：以为把 time.Time 换成 *time.Time 就一定更小——其实 time.Time 是 24 字节结构体，*time.Time 是 8 字节指针，但每次 new 分配还会额外产生堆内存开销和 GC 压力，得权衡。
- 适合改指针的字段：可选、稀疏、大尺寸（如
[]byte、map[String]Interface{}、嵌套大结构体） - 不适合的：小基础类型（
int、bool）、高频访问且几乎不为零的字段（指针解引用有间接成本） - 验证方式：用
unsafe.Sizeof对比前后大小，再用pprof观察实际堆分配量
如何安全地把结构体字段从值改为指针
改指针不是简单加个 *，必须同步处理初始化、零值判断和序列化逻辑。最常见错误是忘记初始化导致 panic：panic: runtime Error: invalid memory address or nil pointer dereference。
- 初始化时统一用构造函数，避免零值结构体直接使用字段指针：
func NewUser() *User { return &User{Age: new(int)} } - 读取前必判空：
if u.Name != nil { fmt.Println(*u.Name) }，别假设非 nil - jsON 序列化需注意：
json.Marshal对 nil 指针字段默认输出NULL，若想跳过，加 tag：Name *string `json:",omitempty"` - 数据库 ORM（如 GORM）通常支持指针字段，但迁移时要确认是否自动处理零值映射
嵌套结构体指针 vs 字段指针：哪个更省
优先把整个嵌套结构体设为指针，而不是把它的内部字段全改成指针。例如：type User { Profile *Profile } 比 type Profile { Name *string, Age *int } 更可控、更易维护。
立即学习“go语言免费学习笔记（深入）”；
原因：嵌套结构体本身可能很大（比如含多个 slice 或 map），用指针只存一个地址；而把每个小字段都指针化，会增加 nil 判断密度、降低缓存局部性，且总指针数多，GC 扫描压力反而上升。
- 典型场景：API 响应结构中，
Address是可选字段，直接定义为*Address，而非让Address.Street、Address.City全是*string - 例外情况：某个字段极大概率为空且极小（如
*bool），而其余字段几乎总是存在，此时单独指针化该字段更精准 - 用
go tool compile -gcflags="-m"可查看编译器是否将结构体逃逸到堆，辅助判断指针引入的实际影响
指针优化后性能下降？检查这三点
改完指针发现吞吐掉、延迟升，大概率踩了这三个坑：
- 频繁
new(T)导致小对象堆分配激增，触发 GC 频繁 —— 改用对象池（sync.Pool）复用，尤其在 http handler 中 - 结构体从栈分配变成堆分配（逃逸分析显示
... escapes to heap），CPU 缓存命中率下降 —— 用go build -gcflags="-m -m"确认逃逸点 - 并发读写未加锁，多个 goroutine 同时修改同一指针目标 —— 指针本身是原子的，但所指数据不是，需按实际读写模式加
sync.RWMutex或改用不可变设计
指针优化本质是空间换时间或空间换确定性，不是银弹。真正省下的往往是内存总量和 GC 周期，而不是单次操作耗时；如果结构体实例生命周期短、数量少，优化收益几乎为零，还增加理解成本。