结构体传值或传指针需依场景判断：≤16字节只读宜传值，>128字节高频调用宜传指针，需修改原值必须传指针；字段对齐、逃逸分析、接口方法集匹配等均影响实际性能。
小结构体传值更快，但临界点不是拍脑袋定的
实测表明，在 amd64 架构、Go 1.23+ 下，结构体大小在 64–128 字节 区间时，值传递和指针传递性能差异通常小于 10%，基本可忽略；小于 64 字节（如 struct{int64; string}，约 32 字节）时，值传递反而快 5–10%，因为避免了指针解引用和潜在缓存未命中。但别凭经验猜——string 和 slice 是 header（24 字节），值传只拷贝 header，不等于底层数组没开销；真正代价来自后续扩容或修改触发的 backing array 复制。
- 用
go test -gcflags="-m"查逃逸，如果值传参数仍逃逸到堆，那“传值省拷贝”的假设就崩了 - 字段顺序影响内存对齐，
[64]byte和struct{int; [64]byte}实际大小可能差 8 字节，测试前要固定布局 - 不要只看结构体字段总和，还要算 padding ——
go tool compile -S或unsafe.Sizeof才是真相
函数参数选值还是指针？看三个硬条件
不是“大就用指针”，而是看是否同时满足：需修改原值、结构体真实体积超临界、调用频次高。比如一个 120 字节 的结构体，若只在初始化时传一次，用指针毫无意义；反过来，一个 24 字节 的结构体，如果方法集里已有指针接收者（如 func (u *User) Save()），那所有地方统一用 *User 更安全，避免接口赋值失败。
- 必须用指针：需要修改原始数据（如
func resetConfig(c *Config)） - 倾向用指针：结构体 >128 字节，且函数被高频调用（如 HTTP handler 中解析请求体）
- 倾向用值：结构体 ≤16 字节（两个 machine word），且只读（如
type Point struct{X, Y int}的计算函数） - 警惕陷阱：即使结构体小，若含
map/slice字段，值传虽快，但底层数据仍共享 —— 这不是“值语义”
切片里存结构体值 or 指针？性能差出一个数量级
往切片里追加结构体，开销差异极大。实测 MyStruct{} 约 112 字节，append(s, MyStruct{}) 每百万次耗时约 3528 ns/op；而 append(s, &MyStruct{}) 仅 246 ns/op —— 差 14 倍。这不是因为指针“快”，而是因为值传每次复制 112 字节，指针传只压栈 8 字节。
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
- 存值适合：结构体极小（≤16 字节）、生命周期短、不跨 goroutine 共享
- 存指针适合：结构体 ≥64 字节、需在多个函数间传递、或切片本身长期存活（否则 GC 压力会上升）
- 注意副作用：存指针后，
s[0].Field = x会改原始对象；存值则不会 —— 语义差异比性能更关键
接口赋值失败？大概率是接收者类型不匹配
定义了 func (u *User) GetName() string，却试图把 User{} 赋给 namer interface{ GetName() string }，编译直接报错：cannot use User{} (value of type User) as namer value in assignment: User does not implement namer (GetName method has pointer receiver)。这不是性能问题，而是类型系统硬约束。
立即学习“go语言免费学习笔记（深入）”；
- 值类型
T的方法集只包含值接收者方法 - 指针类型
*T的方法集包含值接收者和指针接收者方法 - 解决办法只有两个：要么统一用
*T做实参，要么把方法改成值接收者（前提是不需要修改T） - 标准库惯例：
error、io.Reader等小类型用值；http.Client、sql.DB等大结构体用指针
最常被忽略的点：性能差异永远依赖具体场景。一个 40 字节 的结构体，在循环里每秒调用十万次，值传和指针传可能差 3%，但若这个结构体还导致 20% 的变量逃逸到堆上，那 GC 延迟可能吃掉全部优势。不测，就别下结论。
