Go中避免slice底层复制需用unsafe.Pointer构造视图，sync.Pool复用临时对象须清空内容且防逃逸，string与[]byte转换应优先用unsafe.String零拷贝，struct字段按大小倒序排列可减少padding和cache miss。
用 unsafe.Pointer 绕过 slice 底层复制（但得自己管好生命周期）
Go 的 slice 赋值或传参时默认是结构体拷贝（含 ptr、len、cap），不复制底层数组，这点常被误认为“零拷贝”。但如果你频繁调用 append 或切片重切（如 s[100:200]），底层数组可能被扩容或截断，触发内存复制。真正想避免拷贝，得直接操作底层数据指针。
比如从一个大 []byte 中提取子片段又不想复制内容，可以这样：
func sliceFromBytes(b []byte, from, to int) []byte {
if from < 0 || to > len(b) || from > to {
return nil
}
hdr := (*reflect.SliceHeader)(unsafe.Pointer(&b))
subHdr := reflect.SliceHeader{
Data: hdr.Data + uintptr(from),
Len: to - from,
Cap: hdr.Cap - from,
}
return *(*[]byte)(unsafe.Pointer(&subHdr))
}⚠️ 注意：subHdr.Cap 必须保守计算，否则后续 append 可能覆盖相邻内存；该 slice 生命周期不能超过原 b 的生命周期，否则会 dangling pointer。
用 sync.Pool 复用临时对象，尤其 []byte 和 strings.Builder
高频分配小块内存（如 HTTP handler 中的 JSON 缓冲区、日志拼接）是 GC 压力主因。直接 make([]byte, 0, 1024) 每次都新分配，不如从池里取。
立即学习“go语言免费学习笔记（深入）”；
常见错误是把 sync.Pool 当成通用缓存——它不保证对象一定复用，且会在 GC 时清空所有闲置对象。
-
New函数只在池空时调用，别在里面做昂贵初始化 - 归还前清空内容（如
buf = buf[:0]），否则下次取出可能带脏数据 - 不要归还已逃逸到 goroutine 外的对象（比如传给异步 channel 后再放回池）
示例：
var bytePool = sync.Pool{
New: func() interface{} {
return make([]byte, 0, 512)
},
}
func getBuffer() []byte {
b := bytePool.Get().([]byte)
return b[:0] // 清空长度，保留底层数组
}
func putBuffer(b []byte) {
if cap(b) <= 4096 { // 防止过大对象长期占池
bytePool.Put(b)
}
}
避免 string ↔ []byte 来回转换
每次调用 []byte(s) 或 string(b) 都会触发一次底层数组拷贝（即使 Go 1.20+ 对某些场景做了优化，也不应依赖）。如果只是读取内容，优先用 unsafe.String（Go 1.20+）或 unsafe.Slice 直接构造视图。
例如解析协议头时，你有一段只读 []byte，需要当字符串比对：
// ❌ 触发拷贝
if string(hdr[:4]) == "HTTP" { ... }
// ✅ 零拷贝（Go 1.20+）
if unsafe.String(&hdr[0], 4) == "HTTP" { ... }
// ✅ 兼容旧版（需确保 hdr 不为空）
if bytes.Equal(hdr[:4], []byte("HTTP")) { ... } // bytes.Equal 内部用汇编优化，不转 string
更关键的是：别为了“方便”把整个请求体转成 string 再用 strings.Split —— 改用 bytes.Split，它接受 []byte，全程无拷贝。
struct 字段顺序影响内存占用，间接减少 cache line miss
Go struct 不自动重排字段，字段声明顺序决定内存布局。若把小字段（bool、int8）和大字段（*T、[]byte）穿插写，会导致 padding 增多，单个 struct 占更多 cache line，CPU 读取时浪费带宽。
比如这个 struct：
type BadHeader struct {
valid bool // 1B
id uint64 // 8B → 编译器插入 7B padding
data []byte // 24B
}共占 40B（1+7+8+24），而重排后：
type GoodHeader struct {
id uint64 // 8B
data []byte // 24B → 紧跟，无 padding
valid bool // 1B → 放最后，padding 只加 7B 到末尾
}仍占 40B，但访问 id 和 data 更可能落在同一 cache line；若字段更多，收益更明显。用 go tool compile -gcflags="-m" 可看编译器提示的 padding 大小。
实际优化中，字段顺序只是辅助手段，真正影响性能的还是数据访问模式和是否引入了不必要的拷贝。别为了省几个字节去重构整个 struct，但新建类型时顺手按大小倒序排一下，成本几乎为零。
