Go 函数传参时，struct 值传递和指针传递到底差多少？
差的是拷贝开销——不是“有没有影响”，而是“影响多大、什么时候必须改”。struct 小（比如 type Point struct{ X, Y int }），值传没问题；一旦字段多、含切片/字符串/接口/嵌套结构体，值传就会触发整块内存复制，CPU 和 GC 压力立刻可见。
常见错误现象：bench 显示函数耗时突增、pprof 发现大量 runtime.mallocgc 调用、修改入参字段却不生效（误以为是引用语义）。
- 值传递：每次调用都复制整个
struct内存布局（包括内嵌字段的值），哪怕其中某个字段是[]byte，也只复制其 header（3 字段：ptr/len/cap），但 header 本身仍被拷贝 - 指针传递：只传 8 字节地址（64 位系统），无拷贝成本，但要注意：被调函数能直接修改原结构体字段
- 编译器不会自动把大
struct优化成指针传——它严格按签名来，不猜意图
怎么判断一个 struct 算“大”？看 unsafe.Sizeof 结果
别凭感觉。Go 没有统一阈值，但经验上超过 48 字节就该警惕，超过 128 字节基本建议用指针。
实操建议：在开发阶段加个临时检查
立即学习“go语言免费学习笔记（深入）”；
import "unsafe"
type Heavy struct {
ID int64
Name string // 16 字节
Tags []string // 24 字节
Config map[string]string // 8 字节（仅 header）
Data [64]byte
}
// unsafe.Sizeof(Heavy{}) → 输出 160 字节
注意：unsafe.Sizeof 只算结构体自身内存布局（含对齐填充），不算 map/slice 底层数据所占堆内存——那部分虽不拷贝，但 header 复制 + 频繁小对象分配仍会拖慢 GC。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
method 接收者用值还是指针？和性能有关，但更关乎语义
接收者类型决定方法能否修改原始值，也间接影响调用方是否被强制取地址——这是容易被忽略的隐式成本。
常见错误现象：给值接收者方法传了大 struct 变量，结果每次调用都拷贝；或者想修改字段却用了值接收者，改了等于没改。
- 值接收者（
func (s MyStruct) Do()）：适合小、不可变、纯计算类方法；调用时若变量是&v，Go 会自动解引用再拷贝，反而多一次间接寻址 - 指针接收者（
func (s *MyStruct) Do()）：必须用指针调用，但如果变量是值（v），Go 会自动取地址（前提是v是可寻址的）；若v是 map/slice 中的元素或函数返回值，则无法取地址，直接报错cannot call pointer method on ... - 混用风险：同一个类型，如果既有值接收者方法又有指针接收者方法，会导致方法集分裂——接口实现可能意外失败
结构体内含 sync.Mutex 或其他非拷贝字段时，只能用指针
这不是性能问题，是编译错误。Go 禁止拷贝含 sync.Mutex、sync.Once、chan、map、func 等字段的结构体，因为它们内部有不可复制的状态。
错误信息典型长这样：cannot assign to struct containing sync.Mutex in field ... 或 invalid operation: cannot take address of ...（当试图对不可寻址值调用指针方法时）。
- 只要结构体定义里嵌了
sync.Mutex，就必须全程用指针传递、指针接收者、指针初始化（&MyStruct{}） - 别想着“我保证不拷贝它”，Go 在编译期就拦住——这是语言级防护，不是运行时警告
- 即使 Mutex 字段是匿名嵌入，也一样触发检查
真正麻烦的不是记住规则，而是当结构体从简单变复杂、中途加了个 sync.RWMutex，所有已有值传递逻辑全得翻出来改——这种演进式变更最容易漏掉边缘调用点。
