go中大结构体传值必须用指针：超64字节、含map/slice/chan或需修改原值时，值拷贝引发显著性能损耗；深拷贝应慎用，优先显式clone()。
struct 拷贝在 Go 中不是“要不要优化”的问题，而是“什么时候必须用指针”的问题——值拷贝本身没错，但大结构体直接传值会吃掉 CPU 和内存带宽，尤其在高频数据处理场景下，性能损耗肉眼可见。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
结构体赋值时到底发生了什么
Go 对 struct 默认做的是**字段级逐个复制**，不是深浅拷贝的二选一，而是取决于字段类型：
- int、string、bool 等基本类型：值被完整复制
- []byte、map[string]int、chan int：只复制 header（比如 slice 的 data 指针、len、cap），底层数据不复制
- *T 类型字段：只复制指针地址，目标对象仍共享
这意味着：p2 := p1 后，修改 p2.Name 不影响 p1.Name，但修改 p2.Data[0]（假设 Data 是切片）很可能同时改到 p1.Data[0]。
函数传参时 struct 值拷贝的性能陷阱
当结构体超过 64 字节（约 8 个 int64 字段），CPU 缓存行填充和内存搬运开销开始明显上升。实测一个含 3 个 map[string]*T 和 2 个 []byte 的结构体（约 200B），传值调用比传指针慢 3.2 倍（基准测试环境：Go 1.23，AMD Ryzen 7）。
常见误判场景：
- 把 func process(s MyStruct) 当成“轻量操作”，实际每次调用都触发一次内存块复制
- 在 for 循环内反复传入大 struct，导致 GC 压力陡增（因为临时副本堆上分配）
- 接口赋值隐含拷贝：var i interface{} = myStruct 也会复制整个结构体，不只是指针
什么时候该用 *MyStruct 而不是 MyStruct
别等出性能问题再改，按这几条硬规则判断：
- 结构体字段总大小 > 64 字节 → 默认用指针传参
- 含有 map、slice、chan 或任意指针字段 → 即使很小，也优先用指针（避免意外共享）
- 函数需要修改原结构体字段 → 必须用指针，否则修改无效
- 作为 map 的 value 或 channel 的元素 → 值拷贝可能引发不可预期的内存增长（尤其是 map value 是大 struct 时）
深拷贝不是银弹，别轻易用 gob 或 json
真正需要独立副本（比如并发写不同副本）时，才考虑深拷贝。但要注意：
- encoding/gob 和 encoding/json 都依赖反射，单次拷贝耗时是定制化拷贝的 200+ 倍（实测：gob 454µs vs 手写 2µs）
- json 会丢字段标签外的私有字段，gob 要求类型可注册，两者都不支持未导出字段的深层复制
- 最稳妥的方式是为关键结构体写显式 Clone() 方法，只复制真实需要的字段，跳过缓存、锁、临时状态等无关内容
真正卡住性能的，往往不是你没写深拷贝，而是你在不该拷贝的地方反复拷贝——比如把一个带 3 个 map 的 Request 结构体，在中间件链里层层值传递。这种地方，加个 * 比调优序列化快十倍。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
