go中返回* T而非T由语义和性能决定：结构体大、需修改原值、需nil表达“不存在”时应返回指针；基础类型、小结构体、只读配置等绝不该返回指针。
函数返回指针的三个明确信号
Go 中返回 *T 而不是 T，不是风格偏好，而是由语义和性能共同决定的。当出现以下任一情况时，应优先返回指针：
- 结构体字段多、含大数组/切片/map，或
unsafe.Sizeof(T) > 64（粗略经验线）——复制开销明显，返回指针避免栈膨胀 - 调用方需要修改该值，且修改必须反映到原始实例上（比如链式调用
NewCounter().Inc().Inc()） - 需要表达“不存在”语义：返回
nil比返回零值更清晰，例如FindUserByID(999)返回nil表示未找到，而非User{Name: "", Age: 0}
哪些类型绝不该返回指针？
返回基础类型或小结构体的指针，是典型的过早优化，反而引入堆分配和 GC 压力。编译器不会帮你“省”，只会按需逃逸。
-
int、String、time.Time、Error等——它们本身就是值语义，且大小固定（string是 header，但语义不可变） - 字段 ≤2 个的小结构体，如
type Point Struct{ X, Y int }，返回Point更高效、更安全 - 只读配置片段，如
type DBConfig struct{ Host string; Port int }，若构造后不修改，返回值类型更利于内联和栈分配
反例：func GetPort() *int { port := 8080; return &port } —— 完全没必要，还强制逃逸到堆。
构造函数为什么几乎都返回指针？
标准库和主流项目中，NewXXX() 几乎无一例外返回 *T，这不是惯例，而是设计必然：
立即学习“go语言免费学习笔记（深入）”；
- 用户拿到对象后大概率要调用方法（尤其是带指针接收者的方法），若返回值类型，会丢失方法集（
T和*T的方法集不同） - 构造过程常涉及初始化内部 map/slice/channel，这些引用类型本身已共享，返回指针更自然
- 允许后续扩展字段而不破坏 API：加一个大字段不影响返回方式，而值类型扩容可能触发意外拷贝
示例：
func NewBuffer(buf []byte) *Buffer { return &Buffer{buf: buf} } 这里返回指针既避免复制 buf（虽是 slice header，但语义上属于“可变载体”），又确保所有 Write/Read 方法可用。
容易被忽略的坑：nil 检查和文档契约
一旦选择返回指针，就等于把 nil 引入了调用方的控制流。这不是 bug，而是接口契约的一部分——但必须显式声明。
- 不要让
FindUserByID有时返回*User，有时 panic；要么始终返回*User并文档注明 “returns nil if not found”，要么返回(User, bool) - 避免在非必要场景返回可能为
nil的指针（比如GetConfig()应保证非空，否则调用方每处都要判空） - 用
go build -gcflags="-m"观察逃逸分析输出，确认你“以为的大结构体”是否真逃逸——有时候编译器比你更懂优化
最常被忽视的一点：返回指针不等于“必须用指针接收者”，也不等于“结构体一定要导出所有字段”。语义清晰比形式统一更重要。