值类型传参开销取决于大小与调用频次，大struct高频调用压力显著；指针传参未必省内存，需结合逃逸分析；sync.Pool推荐存指针；struct字段应按大小降序排列以减少填充。
值类型传参时内存拷贝开销有多大
Go 中所有值类型（int、struct、[32]byte 等）在函数调用时都会完整复制。拷贝开销取决于类型大小，而非是否“简单”——一个 1KB 的 struct 每次传参就拷贝 1KB，和传一个 int64（8 字节）有数量级差异。
常见误判是认为“小 struct 可以放心值传”，但实际要结合调用频次：高频调用下，哪怕 32 字节的结构体，每秒百万次调用也会带来 32MB/s 内存分配压力。
- 用
unsafe.Sizeof()查看真实大小：fmt.Println(unsafe.Sizeof(MyStruct{})) // 注意：不包含 slice/map/chan 等内部引用所指内容 - 避免在循环内对大值类型（如含数组字段的 struct）做值传递
- 编译器不会自动把值传优化为指针传——这是开发者责任
指针传参真能省内存吗？看逃逸分析
传 *T 确实只传 8 字节地址，但若该指针指向的变量本身逃逸到堆上，反而增加 GC 压力。是否省内存，取决于值本身是否逃逸，而非传参方式。
用 go build -gcflags="-m -l" 观察逃逸行为：
立即学习“go语言免费学习笔记（深入）”；
func f(x MyBigStruct) { ... } // x 通常栈上分配，但若被取地址或闭包捕获，会逃逸
func g(p *MyBigStruct) { ... } // p 是指针，但 *p 对应的值仍可能逃逸
- 加
-l禁用内联，让逃逸分析更准确 - 如果
MyBigStruct{}在函数内创建且未被外部引用，即使传指针，其底层数值仍在栈上——此时指针只是多了一层间接访问，未必更快 - 真正收益场景：复用已有堆对象（如从池中获取）、或避免重复构造大对象
sync.Pool 适合缓存值类型还是指针类型
sync.Pool 存的是 interface{}，底层存储的是值拷贝。存指针类型（如 *MyStruct）可避免每次 Get/Pool 时拷贝结构体内容；存值类型（如 MyStruct）则每次 Get 都需复制一份。
- 推荐存指针：
var bufPool = sync.Pool{ New: func() interface{} { return &bytes.Buffer{} }, } b := bufPool.Get().(*bytes.Buffer) b.Reset() // 复用前必须清空状态 - 值类型仅适用于极小、无内部指针、且构造成本低的类型（如
int32），否则 Pool 反而放大拷贝开销 - 注意：Pool 中对象生命周期不可控，不能假设它一定被复用，也不能依赖析构逻辑
struct 字段顺序影响内存占用？怎么排
Go 的 struct 内存布局遵循“字段按声明顺序排列 + 对齐填充”规则。不合理顺序会导致大量填充字节，尤其混用大小差异大的字段时。
例如：
type BadOrder struct {
a uint8 // offset 0
b uint64 // offset 8（因需 8 字节对齐，前面填 7 字节）
c uint16 // offset 16（因 b 占 8 字节，c 需 2 字节对齐，此处无填充）
} // unsafe.Sizeof = 24
重排为大字段优先：
type GoodOrder struct {
b uint64 // offset 0
c uint16 // offset 8
a uint8 // offset 10 → 后面补 6 字节对齐到 16
} // unsafe.Sizeof = 16
- 用
go tool compile -S或unsafe.Offsetof()验证字段偏移 - 优先按字段大小降序排列：
uint64/float64→uint32/float32→uint16→uint8/bool - 切片、map、channel、string 类型本身是头信息（24 字节），顺序影响小；但它们指向的底层数据不在此优化范围内
