指针传递在结构体≥128字节或含[]byte/map等字段时更快，小结构体（≤32字节）值传递更优；但需结合逃逸分析和基准测试验证，避免因逃逸、解引用或并发竞争导致性能下降或正确性问题。
什么时候指针传递确实更快？看结构体大小和调用频率
不是所有场景下 *T 都比 T 快。真实情况是：结构体越大、函数调用越频繁，指针优势越明显。比如一个含 [1024]byte 和 map[string]interface{} 的结构体，值传递每次复制可能超 4KB；而指针只传 8 字节地址——基准测试中，512 字节结构体的 process(&s) 比 process(s) 快 13 倍以上。
- 结构体 ≤ 32 字节（如
type Point {X, Y int}）：值传递通常更快，编译器能放进寄存器或栈上高效复制 - 结构体 ≥ 128 字节：指针传递几乎总是更优，复制开销成为瓶颈
- 含
[]byte、map、chan或大数组字段：即使结构体本身不大，这些字段的底层数据也可能被隐式深拷贝，用指针可规避
为什么有时候加了 * 反而变慢？逃逸和解引用开销不能忽略
加星号不等于性能优化，它可能把本该在栈上分配的小对象“推”到堆上，触发 GC 压力；还强制引入一次内存寻址（解引用），对高频访问字段造成微小但累积的延迟。
-
go build -gcflags="-m -m"中看到escapes to heap：说明取地址导致变量逃逸，尤其警惕process(&User{...})这种临时构造+取址写法 - 小结构体 + 高频调用（如每毫秒调用千次）：解引用带来的 CPU 指令数增加可能抵消复制节省
- 方法接收器用
func (u *User) GetID()却只读字段：语义冗余，且阻碍编译器内联（can inline输出会消失）
怎么验证你的代码到底要不要加 *？别猜，压测+逃逸分析双管齐下
经验法则容易翻车，真正可靠的判断必须来自工具反馈和实测数据。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 逃逸分析命令：
go build -gcflags="-m -m" main.go | grep -E "(escape|inline)"，重点看参数是否逃逸、方法能否内联 - 基准测试模板：
go test -bench=BenchmarkProcess -benchmem，对比BenchmarkProcessValue和BenchmarkProcessPtr的ns/op和B/op - 关注真实负载：如果函数里主要做 I/O 或网络等待，传参方式差异基本不可测；只有纯计算密集路径才值得抠这几十纳秒
并发场景下用指针，不加锁就是灾难
多个 goroutine 共享同一个 *User 并同时调用 u.Age++，结果大概率错乱——这不是性能问题，是正确性崩塌。
立即学习“go语言免费学习笔记（深入）”；
- 只读共享：可用
sync.RWMutex保护，或改用不可变结构体 + 函数式更新 - 写操作：要么加锁，要么用
atomic（仅限基础类型字段），要么彻底避免共享（如用 channel 传递所有权） - 切记：指针传递本身不提供线程安全，它只是把“共享同一块内存”的事实暴露得更直白
