17370845950

用 unsafe.Slice 预分配切片避免扩容拷贝，strings.Builder 替代 fmt.Sprintf 减少堆分配，sync.Pool 复用临时对象需重置状态，传参优先值类型并避免逃逸。

用 unsafe.Slice 替代 []byte 切片扩容

Go 在对切片追加元素时，若底层数组容量不足，会触发内存拷贝——这是高频性能瓶颈。尤其在解析协议、拼接日志等场景下，反复 append 小块数据会导致多次 malloc + memcopy。

解决思路不是避免追加，而是预先分配足够大的底层数组，并用 unsafe.Slice（Go 1.17+）绕过类型安全检查，直接“视图化”已有内存，避免复制。

• 先用 make([]byte, 0, N) 预分配容量 N，保留零长度但拥有大底层数组
• 后续用 unsafe.Slice(&buf[0], cap(buf)) 获取可写视图，再通过指针偏移写入数据（需手动维护长度）
• 比 bytes.Buffer 更轻量，无锁、无额外字段、不自动扩容
• 注意：跳过 bounds check，越界写入会直接 crash，务必确保偏移 + 写入长度 ≤ 底层数组长度

传递结构体指针而非值，但警惕逃逸到堆

小结构体（如 type Point struct{ X, Y int }）按值传递开销极小；但若函数参数是值类型且被取地址（&p），或赋给全局变量、传入接口、闭包捕获等，编译器会将其“逃逸”到堆上——这反而引入了额外的堆分配和 GC 压力。

真正要减少的是「不必要的堆分配」，不是盲目加 *。

• 用 go build -gcflags="-m" 查看变量是否逃逸，重点关注 ... escapes to heap
• 若结构体字段含指针、slice、map、channel 或 interface，即使很小也大概率逃逸
• 对只读场景，func f(p Point) 比

  

  func f(p *Point) 更可能留在栈上
• 若必须传指针，确保调用方的结构体本身未逃逸（比如局部变量，非 make 分配）

复用 sync.Pool 管理临时对象，但别滥用

sync.Pool 适合生命周期短、创建开销大、且能安全复用的对象（如 *bytes.Buffer、自定义解析器、JSON 解码器）。但它不是万能缓存，误用反而增加 GC 和调度负担。

• 池中对象可能被任意 goroutine 拿走，必须保证状态干净——每次 Get() 后要重置字段，不能依赖构造函数
• 不要把带 finalizer 的对象放进去，Put() 不会触发 finalizer
• 池中对象可能被 GC 清理掉，Get() 可能返回 nil，需做空值检查并重建
• 对单次调用即销毁的小对象（如 int、string），用池毫无意义，还增加原子操作开销

var bufPool = sync.Pool{
	New: func() interface{} {
		return &bytes.Buffer{}
	},
}

func process(data []byte) {
	buf := bufPool.Get().(*bytes.Buffer)
	buf.Reset() // 必须重置！
	buf.Write(data)
	// ... use buf
	bufPool.Put(buf)
}

用 strings.Builder 替代 fmt.Sprintf 拼接字符串

fmt.Sprintf 内部使用 reflect 和格式解析，对简单字符串拼接属于“杀鸡用牛刀”。更严重的是，它每次都会新建 []byte，再转成 string，产生两次堆分配。

strings.Builder 是零拷贝拼接方案：底层用 []byte，Write 直接追加，String() 仅做类型转换（Go 1.10+ 保证不拷贝底层字节）。

• 仅适用于纯字符串拼接，不支持格式化（如 %d）；需要格式化时，先用 strconv 转换再 WriteString
• 避免调用 Builder.String() 后继续 Write —— 此时底层可能已转为只读，再次写入会 panic
• 如果拼接结果最终要转成 []byte，直接用 Builder.Bytes()，比 []byte(String()) 少一次拷贝

真正难的是权衡：预分配大小是否合理？池对象清理时机是否可控？Builder 是否被意外复用？这些细节不盯住，优化就变成负优化。