Go结构体传值还是传指针？

Go语言中结构体参数默认按值传递，意味着函数内修改不会影响原始变量，但若结构体包含切片、map或channel等引用类型字段，则会引发隐式共享风险；小而纯的结构体传值安全高效，而需修改状态、含引用字段或体积较大（尤其超64字节）时，必须使用指针传递以避免性能损耗和并发隐患——关键不在结构体大小本身，而在于字段是否携带共享语义，不确定时优先选择指针，这既是Go标准库的通用实践，也是规避陷阱最稳妥的方式。

结构体作为函数参数时，默认是传值

Go 语言中，所有参数传递都是值传递，struct 也不例外。哪怕结构体很大，调用函数时也会完整复制一份。这意味着：函数内对结构体字段的修改，不会影响原始变量。

常见错误现象：func modify(s MyStruct) { s.Field = "new" } 调用后原 s 毫无变化——因为改的是副本。

• 小结构体（如 type Point struct{ X, Y int }）传值开销小，语义清晰，推荐直接传值
• 大结构体（含切片、map、channel 或大量字段）传值会触发内存拷贝，性能下降明显
• 若函数需修改结构体状态，必须传指针，否则无效

什么时候必须用 *struct 而不是 struct

当函数需要「修改调用方持有的结构体实例」时，指针是唯一选择。这不是风格问题，而是语言机制决定的。

典型场景包括：

• 初始化未导出字段（如私有 sync.Mutex）：func (s *MyStruct) Init() { s.mu = sync.Mutex{} }
• 实现接口方法且方法集需包含指针接收者（例如 io.Writer 要求 Write([]byte) (int, error) 必须在 *MyWriter 上定义）
• 避免重复拷贝大数据字段（如结构体内嵌 []byte 或长字符串）

注意：一旦结构体某个方法用了指针接收者，为保持方法集一致，其他方法也建议统一用指针接收者，否则容易出现「方法集不匹配」导致接口赋值失败。

结构体字段含 slice/map/chan 时传值的陷阱

虽然 struct 本身传值会复制，但其中的 slice、map、chan 是引用类型，其底层数据结构（如底层数组、哈希表）不会被复制。这造成一种“半共享”状态：

• 传值后，新结构体的 slice 仍指向原底层数组；append 可能意外影响原结构体（尤其发生扩容时行为不可控）
• map 字段传值后，两个结构体操作同一张哈希表，并发读写直接 panic
• 这种隐式共享比纯值拷贝更危险，因为表面看是“隔离”的，实际却共享状态

示例：type Config struct{ Data []int }，若函数内执行 c.Data = append(c.Data, 1)，原 Data 是否变化取决于是否扩容——逻辑难以预测。

如何快速判断该传 struct 还是 *struct

不必纠结“最佳实践”，按以下三点决策即可：

• 只读小结构体（≤ 3–4 个基础字段）→ 直接传 struct，安全且无性能负担
• 需修改、含引用字段、或结构体尺寸 > 64 字节 → 传 *struct，明确意图并规避拷贝与共享风险
• 不确定？先用 *struct。Go 标准库绝大多数结构体（如 http.Client、json.Encoder）都设计为指针使用，这是经过验证的惯用法

真正容易被忽略的点是：字段类型比结构体大小更重要。一个 16 字节的 struct 含一个 map[string]int，它比 128 字节纯字段的 struct 更应传指针。

今天关于《Go结构体传值还是传指针？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！