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 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 —— 这样调用方无需条件判断就能用

真正难的不是“怎么用指针”，而是“为什么这里必须用”。当发现某个指针只为绕过编译器检查、适配第三方库签名、或延续历史包袱时，就该停下来重画数据边界了。