值拷贝是否慢取决于结构体大小、内存局部性及编译器优化：≤128字节通常无开销，＞512字节才明显变慢；应按语义（修改/共享/大且高频）而非单纯尺寸决定是否用指针。
大结构体传参时值拷贝真的慢吗
Go语言中，值类型（比如 struct）作为参数传递时会完整复制，但“慢不慢”不能一概而论——它取决于结构体大小、内存局部性、编译器优化程度。实测表明：小于 128 字节的结构体，现代 Go 编译器（1.20+）大概率通过寄存器或栈内摊平传递，几乎无额外开销；超过 512 字节后，拷贝开始明显拖慢调用性能，尤其在高频小函数中。
常见错误现象是：没测就加 *，结果引入空指针 panic 或意外共享状态；或者反过来，对一个仅含 3 个 int 的结构体硬套指针传参，反而因解引用和缓存未命中变慢。
- 用
go tool compile -S查看汇编，确认是否发生实际内存拷贝（搜索MOVQ大块连续移动） - 基准测试必须包含调用上下文：单独测拷贝本身意义不大，要测真实函数调用链路
- 注意逃逸分析：
go build -gcflags="-m"看结构体是否因传指针而被迫堆分配
什么时候该用指针传参而不是值
不是“大才用指针”，而是“改、共享、大且不逃逸”三者满足其一时才值得切换。核心判断依据是语义而非尺寸。
- 函数需要修改原值 → 必须传
*T - 多个地方需共享同一份数据（如配置缓存、连接池项）→ 传
*T避免不一致 - 结构体 > 1KB 且调用频次高（如每毫秒调用数十次的渲染逻辑）→ 优先考虑指针
- 结构体含
sync.Mutex或其他不可拷贝字段 → 编译器强制要求传指针
反例：一个只读的 type Point struct{ X, Y float64 }，传值更高效，也更安全——没有意外别名风险。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
逃逸分析如何影响你的选择
加 * 不等于省内存。如果本可栈分配的结构体因取地址而逃逸到堆上，GC 压力和分配延迟可能比拷贝还贵。
典型场景：func foo() *MyBigStruct { return &MyBigStruct{} } —— 这里指针本身没省事，反而制造了堆对象。
- 用
go run -gcflags="-m -l" main.go检查变量是否逃逸（关键词：moved to heap） - 若结构体只在单个函数内使用且生命周期明确，即使稍大，保持值传递 + 内联（
//go:noinline反向验证）往往更优 - 避免在循环中反复取地址并存入切片：
for _, v := range data { ptrs = append(ptrs, &v) }→ 全部指向最后一个元素
替代方案：零拷贝视图与切片包装
对只读大对象（如解析后的 JSON 数据、图像像素缓冲区），与其传整个结构体或裸指针，不如提供轻量视图类型。
例如：
type ImageData struct {
pixels []byte
width, height int
}
// 不传 *ImageData，而是传只读视图
type ImageView struct {
data []byte
width, height int
}
这种模式把底层数据所有权留在原处，只传递描述信息（通常
真正容易被忽略的是：大对象优化从来不是“选值还是指针”的二选一，而是结合使用场景、逃逸行为、访问模式做权衡。一次不恰当的指针化，可能让 GC 成为瓶颈；一次盲目的值传递，又可能让 CPU 缓存失效。动手前，先跑 go tool compile -S 和 go tool trace。
