该用 *T 而不是 T 传参时：结构体字段超4–5个或含 []byte、map、[1024]byte 等大字段，避免整块内存拷贝；需修改原对象状态时必须用指针；小结构体传值更快；slice/map/chan 本身轻量，应直接传值。
什么时候该用 *T 而不是 T 传参
结构体字段超过 4–5 个，或含 []byte、map、[1024]byte 这类大字段时，用指针传参能避免整块内存拷贝。比如 type User struct { Name string; Avatar []byte; Meta map[string]string }，传 *User 只拷贝 8 字节地址，而传 User 可能拷贝几百甚至上千字节。
- 小结构体（如
type Point struct{ X, Y int }）传值更快——解引用开销比拷贝还贵 -
slice、map、chan本身是轻量头结构（通常 24 字节），直接传值即可，func f(data *[]int)是错的，易触发nilpanic - 需要修改原对象状态时必须用指针，否则函数内改了也白改
为什么 func NewX() *X 有时反而更慢
返回局部变量地址（如 u := X{}; return &u）会强制变量逃逸到堆，每次调用都触发一次堆分配和 GC 压力。编译器看到取地址并返回，基本就判“逃逸”。
- 用
go build -gcflags="-m" main.go检查：若输出... moved to heap，说明已逃逸 - 更优写法是返回值类型：
func NewUser() User { return User{Name: "A"} }，由调用方决定放栈还是堆 - 真要返回指针，优先用
sync.Pool复用，而不是每次都&X{}
结构体字段用不用指针，不只是性能问题
把 Name string 改成 Name *string 看似省内存，实则引入一连串语义风险：JSON 序列化默认不输出 nil 字段、数据库扫描可能 panic、业务逻辑里容易漏掉 if u.Name != nil 判断。
- 仅当字段明确表示“未提供”（如 API 请求中可选字段）才用指针
- 数据库场景优先用
sql.NullString，它显式封装了Valid和String，比裸*string安全得多 - 基本类型（
int、bool）几乎不该用指针字段——你真需要区分 “0” 和 “未设置” 吗？多数时候只是给自己埋坑
结构体内存布局怎么影响指针效果
字段顺序直接影响结构体大小，差一两个字段位置，unsafe.Sizeof 可能差出 33%。比如 bool 放在 int64 前面，编译器得插 7 字节 padding；反过来，padding 就挪到末尾，总大小更紧凑。
立即学习“go语言免费学习笔记（深入）”；
- 按类型大小降序排：先
int64、float64，再int32、string，最后bool、int8 - 频繁访问的字段尽量靠前，提升缓存行（64 字节）命中率
- 大字段（如图片数据）考虑用指针延迟加载，让热字段集中，冷字段分离，别一股脑塞进主结构体
... escapes to heap —— 它比任何直觉都准。 
