优先按值返回小结构体（≤8字节），大结构体或含不可复制字段（如sync.Mutex）时返回指针；需调用指针接收者方法或修改原值时也应返回指针。
返回结构体还是指针？看值大小和是否需要修改
Go 中函数返回 struct 还是 *struct，核心取决于两点：结构体大小、以及调用方是否需要修改原值。小结构体（比如 type Point struct{ X, Y int }）按值返回开销小，且天然线程安全；大结构体（字段多、含 slice/map/interface 或嵌套深）返回指针能避免复制，性能更优。
常见误判是“只要可变就返回指针”——但 Go 的接口实现不依赖指针接收者，只要方法集匹配即可。真正需要指针的场景是：调用方后续要修改该结构体字段，或结构体本身包含不可复制字段（如 sync.Mutex）。
- 结构体总大小 ≤ 机器字长（通常 8 字节），优先返回值
- 含
sync.Mutex、map、slice、chan等字段，必须返回指针（否则编译报错：invalid operation: cannot take address of ...） - 若结构体有指针接收者方法，而你希望调用方能通过接口变量调用这些方法，那返回指针更稳妥（值接收者方法也能被接口调用，但指针接收者方法不能被值变量调用）
接口变量持有值还是指针？影响方法集匹配
接口变量存储的是具体类型的“值”或“指针”，这直接决定它能调用哪些方法。如果一个结构体 Foo 只有指针接收者方法 (*Foo).Do()，那么 var x Foo 无法赋值给该接口，而 var x *Foo 可以。这不是性能问题，而是编译期类型检查。
典型错误：定义了 func (f *Foo) ServeHTTP(...)，却返回 Foo{} 给 http.Handler 接口，结果编译失败：Foo does not implement http.Handler (ServeHTTP method has pointer receiver)。
立即学习“go语言免费学习笔记（深入）”；
- 接口方法签名和接收者类型必须严格匹配，不是“自动取地址”
- 若结构体同时有值和指针接收者方法，返回值或指针都可满足接口，但行为不同：值返回时，指针接收者方法内部对
self的修改不会反映到原值（因为是副本） -
标准库倾向返回指针（如
json.NewDecoder、os.Open），既是惯例，也因底层资源需唯一所有权
逃逸分析决定堆分配，不是返回方式本身
很多人以为“返回指针 = 分配在堆上”，其实不然。是否逃逸由编译器静态分析决定，和返回 struct 还是 *struct 没有必然联系。例如：
func NewPoint() *Point {
p := Point{X: 1, Y: 2} // 这里 p 很可能逃逸到堆
return &p
}
而：
func GetPoint() Point {
return Point{X: 1, Y: 2} // 完全不逃逸，直接返回寄存器或栈拷贝
}
用 go build -gcflags="-m" 查看逃逸分析结果比凭经验猜测更可靠。盲目加 * 不仅没提升性能，还增加 GC 压力。
- 返回局部变量地址才可能触发逃逸；返回字面量或参数传入的值，通常不逃逸
- 结构体含指针字段（如
data *[]byte）会提高逃逸概率，但根源是字段语义，不是返回方式 - 性能关键路径建议实测：用
benchstat对比BenchmarkReturnStruct和BenchmarkReturnPtr
对外 API 设计：一致性比微观优化更重要
包的公共函数返回风格应统一。比如 net/http 全部返回指针，time 包多数返回值（time.Now() 是 Time 值）。用户依赖这种一致性做内存预期和错误处理。
一旦暴露指针，就等于承诺该对象生命周期由调用方管理（或至少不保证内部不变性）；返回值则暗示不可变性与廉价拷贝。混用会让使用者困惑：为什么这个 Config 返回指针，那个 Option 却返回值？
- 如果结构体未来可能扩展（加字段、加 mutex），初始就返回指针，避免 v2 版本破坏兼容性
- 导出字段少、纯数据结构（DTO），返回值更直观；含行为、状态或资源封装（如 client、cache、pool），返回指针更合理
- 文档中明确写清：“返回值为只读副本” 或 “返回的对象可被安全并发修改”，比纠结语法细节更重要
