Go中结构体参数默认传值，修改不影响原变量；需修改状态、含引用字段或体积大时必须传指针，以避免拷贝开销与隐式共享风险。
结构体作为函数参数时，默认是传值
Go 语言中，所有参数传递都是值传递，struct 也不例外。哪怕结构体很大，调用函数时也会完整复制一份。这意味着：函数内对结构体字段的修改，不会影响原始变量。
常见错误现象：func modify(s MyStruct) { s.Field = "new" } 调用后原 s 毫无变化——因为改的是副本。
- 小结构体（如
type Point struct{ X, Y int }）传值开销小，语义清晰，推荐直接传值 - 大结构体（含切片、map、channel 或大量字段）传值会触发内存拷贝，性能下降明显
- 若函数需修改结构体状态，必须传指针，否则无效
什么时候必须用 *struct 而不是 struct
当函数需要「修改调用方持有的结构体实例」时，指针是唯一选择。这不是风格问题，而是语言机制决定的。
典型场景包括：
立即学习“go语言免费学习笔记（深入）”；
- 初始化未导出字段（如私有 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 更应传指针。
