用 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语言免费学习笔记（深入）”；
- 用
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 是否被意外复用？这些细节不盯住，优化就变成负优化。
