小结构体值传递通常更快或持平，因CPU缓存友好且避免解引用开销；≤16字节优先用值类型，大结构体才需指针以避免隐形拷贝。

指针传递不一定更快，小结构体传值反而更优

很多人默认“指针 = 性能更好”，但基准测试反复证明：对于小结构体（比如 struct{X, Y int} 或 struct{ID int64; Name string}），值传递通常更快或持平。原因很实在——现代 CPU 缓存对紧凑的小对象友好，而指针多一次解引用（*p）、且可能触发额外的内存访问，反而拖慢热点路径。

• 典型阈值：≤ 2 个 machine word（即 ≤16 字节，在 64 位系统上）的小结构体，优先用值类型
• 常见误判：把 string 当大对象——其实它只有 16 字节（ptr + len），传值开销极低
• 验证方法：go test -bench=. 对比 BenchmarkByValue 和 BenchmarkByPointer，别靠猜

大结构体不传指针，性能会明显掉档

一旦结构体含数组、大缓冲区、多个切片头或嵌套 map，值传递就变成“隐形拷贝大户”。例如 struct{Data [1024]byte; Config map[string]string}，每次调用函数都会复制至少 1KB+ 内存，CPU 和内存带宽压力陡增。

• 指针只传 8 字节地址，开销恒定，与结构体大小无关
• 高频调用场景（如 HTTP 中间件、事件循环处理器）下，差异可达 30%–50%
• 注意逃逸：即使你写的是值传递，若编译器判断该变量“可能被返回或跨 goroutine 使用”，仍会把它分配到堆上——用 go build -gcflags="-m" 查看实际分配位置

性能不是唯一标准，语义和安全常更重要

选指针还是值，不能只看 benchmark 数字。Go 是一门强调可读性与明确性的语言，很多“慢一点但更稳”的选择才是工程常态。

• 需要修改原数据？必须用指针——值传递改了也是白改
• 字段是可选配置（如 *string 表示“未设置”）？指针天然支持 nil，值类型做不到
• 并发场景下，值类型天然隔离，避免数据竞争；指针则需额外加锁或同步机制
• JSON 序列化时，*string 能区分 null 和 ""，值类型 string 无法表达“缺失”语义

最容易踩的坑：nil 指针 panic 和过度指针化

用指针最痛的不是性能问题，而是运行时 panic 和维护成本上升。一个没判空的 *User 字段，上线后可能在某个边缘请求里直接崩掉。

• 所有指针字段访问前必须检查是否为 nil，尤其来自 JSON 解析或数据库扫描的结果
• 不要为所有字段加 *：比如 type Point struct{ X, Y int }，加指针纯属增加 GC 压力和代码噪音
• 方法接收者不统一（部分用值、部分用指针）会导致接口实现断裂——Go 要求方法集一致才能满足接口，这点常被忽略

真正关键的不是“指针快不快”，而是“这个变量要不要被共享、能不能为 nil、改了是不是要影响外面”。性能差异只在结构体超过几十字节且调用频繁时才显著，其他时候，语义清晰比省几个纳秒重要得多。