Go中返回局部变量指针安全但非必要，应避免过度指针化：小结构体、基础类型优先值传递；仅需读取时用值参数；修改字段或结构体过大才用指针接收者；API设计应减少nil检查，优先零值友好和接口抽象。
Go里返回局部变量指针是安全的，但“安全”不等于“该用”——不必要的指针会抬高GC压力、模糊所有权、增加nil panic风险，还可能掩盖设计问题。
什么时候根本不需要指针
小结构体（字段总大小 ≤ 机器字长，如 int64、struct{a,b int}）、基础类型（int、string、bool）传参或赋值时，值传递开销极低，指针反而多一次内存寻址和间接访问。
- 函数参数：若只读且不修改原值，优先用值传递；
func process(u User)比func process(u *User)更清晰、更不易panic - 方法接收者：只有需要修改接收者字段，或结构体过大（>16–32字节）时，才用指针接收者；否则用值接收者避免意外共享
- 构造返回：除非明确要支持
nil表示“未初始化”，否则直接返回User而非*User；NewUser()返回*User合理，但DefaultConfig()返回Config更自然
如何一眼识别“过度指针化”
看代码是否频繁出现以下模式：
- 结构体字段全是指针：
type Config struct { Host *string `json:"host"` Port *int `json:"port"` }—— 这通常意味着API设计妥协（如区分零值与未设置），但日常业务逻辑中多数字段应有合理默认值，用值语义更健壮 - 切片元素存指针：
[]*Item而非[]Item—— 除非Item很大或需跨 goroutine 修改同一实例，否则浪费缓存局部性，且易引发“逻辑野指针”（底层数组扩容后旧地址失效） - 函数链式调用中不断取地址：
&v.Field→&v.Slice[i]→&result—— 这往往说明数据流混乱，应重构为明确的数据生命周期管理
用工具验证指针是否真有必要
逃逸分析不是免检金牌。即使 go build -gcflags="-m" 显示变量“escapes to heap”，也要问一句：这是性能瓶颈吗？还是只是惯性使然？
立即学习“go语言免费学习笔记（深入）”；
- 运行
go build -gcflags="-m -m" main.go，关注是否出现 “moved to heap” 或 “leaks param content” —— 如果只是单次调用的小对象，逃逸影响微乎其微，不必强求栈分配 - 用
go tool pprof对比堆分配热点：如果*T分配占 GC 时间 >5%，再考虑改用值或复用池（sync.Pool） - 启用竞态检测：
go run -race，若指针被多 goroutine 共享却无同步，那不是“要不要指针”的问题，而是“不该共享”的设计缺陷
nil 检查泛滥是危险信号
如果一个函数内部反复写 if p != nil { ... }，或者调用方总要加 if u != nil 才敢调 u.Name，说明指针在这里没带来价值，只增加了防御成本。
- 接口比指针更适合作为可选行为载体：用
type Logger interface{ Log(string) }替代*loggerImpl - 零值友好的结构体天然规避 nil：让
type Cache struct{ mu sync.RWMutex data map[string]string }的零值可用，而非强制要求new(Cache) - 对外暴露的 API 尽量避免返回
nil指针；失败时返回零值 + error，成功时保证非 nil —— 这样调用方无需条件判断就能用
真正难的不是“怎么用指针”，而是“为什么这里必须用”。当发现某个指针只为绕过编译器检查、适配第三方库签名、或延续历史包袱时，就该停下来重画数据边界了。
