传 *User 真正提速需满足结构体字段超4–5个或含大字段（如[]byte、map、[1024]byte），因值传递会完整拷贝，而指针仅传8字节地址；小结构体（≤24字节）传值更快且利于内联。
什么时候传 *User 真的能提速？
结构体字段超过 4–5 个，或者含 []byte、map、[1024]byte 这类大字段时，传 *User 才明显快。因为 Go 是值传递，传 User 就得把整个结构体复制一遍——比如一个带 1KB 数组的结构体，每次调用都拷贝 1024 字节；而 *User 只传 8 字节地址。
- 小结构体（如
type Point struct{ X, Y int }）传值更快：CPU 缓存友好，还可能被编译器内联 -
string、[]int、map[string]int本身已是轻量头结构（24 字节左右），别画蛇添足写成*[]int，反而可能触发逃逸 - 只读场景下用指针，常会“好心办坏事”：编译器无法判断是否可栈分配，强制抬升到堆，增加 GC 压力
为什么 func (u *User) Save() 比 func (u User) Save() 更常用？
两个原因：一是能改原对象字段，二是避免每次调用都复制整个 User。如果 Save() 方法里要改 u.LastModified，用值接收者根本改不动，还白费一次拷贝。
- 方法集不统一容易翻车：同一个结构体，有的方法用值接收者，有的用指针，会导致接口实现不一致（比如
io.Writer要求指针才满足） - 结构体一旦变大，值接收者方法在高频调用中会迅速拖慢性能，压测时
BenchmarkNsPerOp差几倍很常见 - 如果所有方法都不改字段且结构体很小（≤ 24 字节），值接收者反而是更优选择，比如
func (p Point) Distance(q Point) float64
go build -gcflags="-m" 报 “escapes to heap” 是什么意思？
意思是这个变量没待在栈上，被编译器挪到堆里去了，后续由 GC 管理。取地址（&x）是常见诱因，但不是唯一原因——比如返回局部变量的指针、闭包捕获变量、或结构体字段含指针，都可能导致逃逸。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 典型危险模式：
func NewUser() *User { u := User{}; return &u }→u必然逃逸，每次调用都堆分配 - 更安全写法：
func NewUser() User { return User{} }，让调用方决定放哪（可能栈上，也可能结构体嵌入时直接展开） - 想确认影响？加
-m -m多一级输出，看有没有can inline提示：值传递更容易被内联，指针传递常被拦住
结构体字段该不该定义成 *string 或 *int？
几乎不该。一个 int 才 8 字节，包一层指针不仅多一次堆分配、多一次解引用，还引入 nil 判断负担和序列化歧义。只有两种情况例外：
立即学习“go语言免费学习笔记（深入）”；
- 需要明确区分“0”和“未提供”（例如 API 请求中可选字段），此时用
*int或更推荐sql.NullInt64 - 字段本身是真正的大对象（比如
*BigDataReport，体积远超 64 字节），且业务上允许为空或延迟加载 - 把
Avatar []byte改成Avatar *[]byte是典型错误：既没省空间，又增加间接访问，还容易 panic
指针不是压缩包，它不减少数据大小，只改变访问方式。真要省内存，先看结构体字段顺序、对齐填充，再考虑要不要拆分或用 ID 查表。
