在前面的文章中，我们解决了 “方法接收者（输入）” 和 “结构体字段（存储）” 的指针选择问题。现在，我们来到“指针 vs. 值”三部曲的最后一篇：函数返回值（输出）。
当你编写一个函数时，返回值应该定义为 T（值）还是 *T（指针）？
// 方式 A：返回指针
func NewT() *T { ... }
// 方式 B：返回值
func NewT() T { ... }
这个选择不仅关乎性能（内存分配），更关乎代码的安全性和语义。在这篇文章中，我们将通过 3 个典型的编程场景，为你提供一套清晰的决策框架。
场景一：构造函数（New...）
这是最常见的场景。当你创建一个“工厂函数”来初始化对象时，应该返回什么？
我们来看两个 Go 标准库的例子：
例子一：返回 “指针”
// 来自 {GOROOT}/src/bytes/buffer.go
//
// In most cases, new([Buffer]) (or just declaring a [Buffer] variable) is
// sufficient to initialize a [Buffer].
func NewBuffer(buf []byte) *Buffer { return &Buffer{buf: buf} }
例子二：返回 “值”
// 来自 {GOROOT}/src/time/time.go
//
// Now returns the current local time.
func Now() Time {
// ...省略代码...
return Time{...}
}
初看这两个例子，一个返回指针，另一个返回值，似乎在暗示我们：这完全取决于个人喜好，怎么写都行。
绝非如此！
Go 标准库的每一个设计决策背后都有着严密的逻辑。NewBuffer 和 Now 的返回值差异，并非随机选择，而是基于这两个对象截然不同的本质特性和设计意图。
那么，Buffer 和 Time 分别有什么特点，导致了这种差异呢？
bytes.Buffer：可变的状态容器
我们要看的第一个指标，就是这个类型的方法集（Method Set）。请看 Buffer 的核心方法 Write：
// 必须使用指针接收者，因为它需要修改 b 的内部字段
func (b *Buffer) Write(p []byte) (n int, err error) { ... }
Buffer 是一个有状态、可变的对象。当你调用 Write 时，你期望的是修改当前这个Buffer 实例，而不是创建一个新的副本。
如果 NewBuffer() 返回的是值（Buffer），会带来一个隐患：容易引发错误的复制。
Buffer 内部包含切片，如果用户不小心复制了 Buffer（值拷贝），可能会导致两个 Buffer 实例共享同一个底层数组，从而引发严重的逻辑错误或数据竞争。
因此，NewBuffer必须返回指针。这明确告知调用者： “这是一个独一无二的对象，请直接操作它，不要复制它。”
time.Time：不可变的值类型
我们再来看看 Time。它的核心方法 Add 是怎么定义的？
// 使用值接收者，它不会修改 t 本身，而是返回一个新的 Time
func (t Time) Add(d Duration) Time { ... }
Time 的设计理念是“值类型”，就像 int 或 float 一样。因为：
-
它代表一个绝对的时间点。 -
它是不可变的（Immutable）。你无法修改一个时间点，你只能计算出另一个新的时间点。 -
它很小，复制成本极低。
对于这样的类型，返回指针反而非常怪异，你见过谁写个函数返回 *int 吗？因此，Now() 直接返回 Time 值，既自然又高效。
由此，我们可以得出第一个决策法则：构造函数的返回值，应该与类型的方法接收者保持一致。
-
如果类型的方法集主要绑定在 *T（指针）上（如*Buffer、*User），构造函数就返回*T。 -
如果类型的方法集主要绑定在 T（值）上（如Time、Point），构造函数就返回T。
只要遵循这个法则，你的代码就会像标准库一样自然、地道。
注意：
return &MyStruct{}通常会导致这个变量逃逸到堆上，增加 GC 压力。而return MyStruct{}通常可以在栈上完成。如果你的结构体很小且不需要修改，返回“值”可以极大地减轻 GC 压力。
场景二：访问器 / Getter
这是一个关乎 “封装安全” 的关键决策。
假设你的结构体内部持有一个配置对象，你想对外提供一个方法来获取它。
type Service struct {
config Config // 内部状态
}
错误做法：返回指针
// 危险！
func (s *Service) Config() *Config {
return &s.config
}
这就等于把内部数据的“钥匙”（指针）交给了调用者。调用者可以随意修改 s.config 的内容（如 s.Config().Port = 9999），而 Service 对此一无所知。这破坏了封装性，可能导致难以排查的 Bug。
正确做法：返回副本（值）
// 安全
func (s *Service) Config() Config {
return s.config
}
此时，调用者拿到的是一份只读副本。无论他怎么折腾这份副本，Service 内部的原始配置永远是安全的。
⚠️安全贴士：浅复制的陷阱
需要特别注意的是，如果
Config结构体内部包含了map、slice或指针字段，返回“值”只是浅复制。调用者虽然改不了Port，但依然可以恶意修改map或slice里的数据！对于这种情况，如果需要绝对的安全，你可能需要编写深复制（Deep Copy）逻辑，或者返回具体的字段（如
func Port() int），而不是返回整个结构体。
由此，我们可以得出第二个决策法则：对于 Getter 类方法，除非你有明确意图允许外部修改内部状态，否则永远返回“值” 以保护封装。
场景三：数据查询
当我们需要从数据库或缓存中查找数据时，经常面临一个尴尬的问题： “如果没有找到，我该返回什么？” 以及 “数据量大了怎么办？”
在业务开发中，数据库模型（Model）通常包含大量字段（几十个字段是常态）。此时，性能考量往往排在第一位。
不推荐的做法：纯返回指针
func FindUser(id int) *User {
if !found {
return nil // 仅靠 nil 代表“没找到”
}
return &user
}
这种写法虽然性能没问题，但语义模糊。“没找到”和“数据库报错”无法区分。调用者一旦忘记检查 nil，会直接导致 panic。
理论上“安全”的做法：返回 (T, error)
func FindUser(id int) (User, error) { ... }
这彻底消灭了 nil 指针导致的 panic 风险，语义也更加清晰（“没找到”是一个错误，而不是一个空指针）。但是，当 User 结构体很大，或者高频调用时，每次查询都触发一次拷贝，性能开销是不可忽视的。
工程界的最佳实践：返回 (*T, error)
在数据层（Store），综合了性能和语义的最终赢家通常是这样：
func FindUser(id int) (*User, error) {
// 使用 GORM 等 ORM 查询
var user User
err := db.First(&user, id).Error
if err != nil {
// 1. 先判断是否是“记录不存在”
if errors.Is(err, gorm.ErrRecordNotFound) {
returnnil, ErrNotFound
}
// 2. 其他数据库错误（如连接断开），直接返回
returnnil, err
}
// 3. 成功找到：返回指针（零复制）和 nil error
return &user, nil
}
为什么这是最佳选择？
-
性能最优（Zero Copy）： ORM 在堆上创建了对象，我们直接把指针传出去，没有任何多余的内存复制。 -
语义清晰： 通过 error明确区分“系统错误”和“记录不存在”。 -
标准统一： 调用者虽然拿到了指针，但有着统一的错误处理范式： if err != nil。
基于以上分析，我们可以得出第三个决策法则：
-
对于简单的查找（Map 查找、小对象）： 推荐返回 (T, bool)或(T, error)，安全第一。 -
对于数据库/ORM 查询（大对象）： 推荐返回 (*T, error)。性能优先，但必须配合error来进行严谨的错误处理，而不能仅依赖nil。
关于集合：[]T 还是 []*T 呢？
这个问题的逻辑与上一篇结构体字段完全一致。
-
[]T（值切片）：性能之王。内存连续，缓存友好，GC 压力极小（只跟踪 1 个对象）。这是默认首选。 -
[]*T（指针切片）：GC 噩梦。需要跟踪 N+1 个对象。只有当你需要切片里的元素可以为nil，或者必须共享元素指针时才使用（例如：你希望对元素的修改能直接反映到原始对象上）。
总结
最后，对今天这篇文章做一个总结。对于函数返回值的指针选择问题，我们可以遵循下面这份“黄金法则”清单：
-
构造函数（ New...）：跟随方法接收者。如果类型的方法是指针接收者，就返回*T；否则返回T。 -
访问器（ Getter）：默认返回T（值）。保护内部封装，防止外部意外修改。 -
数据查询（ Find...）：-
一般推荐 (T, error)。更安全，语义更清晰。 -
数据库层可用 *T。为了性能（避免大对象拷贝），这是可以接受的例外。
-
-
集合：默认返回 []T。除非你明确需要 共享元素 或 原地修改 它们。
掌握了以上四点，你已经可以从容应对 90% 以上的开发场景了。
至于剩下的特殊场景——比如链式调用（Builder 模式），本质上可以视为构造函数的变体，决策也很简单：
-
如果你希望修改自身状态（Mutable），请返回 *T。 -
如果你希望保持不可变（Immutable，如 time.Add），请返回T。
我们之所以不厌其烦地梳理“指针 vs. 值”的选择问题，归根结底是为了在安全性和性能之间找到最佳平衡。而这其中的关键，正是 Go 编译器的核心机制：逃逸分析。
下一篇文章，我们将深入幕后，揭秘逃逸分析的原理与玄机。敬请期待！