小结构体值传递通常更快或持平，因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 字段，上线后可能在某个边缘请求里直接崩掉。
立即学习“go语言免费学习笔记（深入）”；
- 所有指针字段访问前必须检查是否为
nil，尤其来自 JSON 解析或数据库扫描的结果 - 不要为所有字段加
*：比如type Point struct{ X, Y int }，加指针纯属增加 GC 压力和代码噪音 - 方法接收者不统一（部分用值、部分用指针）会导致接口实现断裂——Go 要求方法集一致才能满足接口，这点常被忽略
真正关键的不是“指针快不快”，而是“这个变量要不要被共享、能不能为 nil、改了是不是要影响外面”。性能差异只在结构体超过几十字节且调用频繁时才显著，其他时候，语义清晰比省几个纳秒重要得多。
