Go · Slice 切片底层

场景 1 · 高并发路径预分配: allocs/op 从 11 降到 1

热路径上切片从空长起, 每次翻倍都是"分配+拷贝+旧数组进 GC", 三重开销:

func withoutPrealloc(n int) []int64 {
    s := make([]int64, 0)                     // 起点 cap=0: 之后 log2(n) 轮搬家拷贝
    for i := 0; i < n; i++ {
        s = append(s, int64(i))
    }
    return s
}
func withPrealloc(n int) []int64 {
    s := make([]int64, 0, n)                    // 已知规模: 一次到位, 0 次再分配
    for i := 0; i < n; i++ {
        s = append(s, int64(i))
    }
    return s
}
// go test -bench=Pre -benchmem
// BenchmarkWithout-8   5841722   205.1 ns/op   16376 B/op  11 allocs/op
// BenchmarkWith-8      7628761    78.4 ns/op    8192 B/op   1 allocs/op

场景 2 · 百万行报表分页: s[start:end] 视图, 0 拷贝

每页 copy 一份 80MB 数据, P99 直接劣化; 返回视图只花 24 字节:

// 100 万行的导出报表: 每次翻页拷贝 = 80MB/页, 网关内存被打爆
func (q *PageQuery) View(all []Row) []Row {
    start := (q.page - 1) * q.size
    if start >= len(all) {
        return nil                             // 越界页: 返回空由上层决定 404
    }
    end := start + q.size
    if end > len(all) {
        end = len(all)                          // 末页不满一页: clamp 到边界
    }
    return all[start:end]                        // 视图: 只拷 header, 数据不动
}
// 契约注释必写: 返回值与 all 共享底层, 调用方只读不可改
// 一旦有人改元素, 本体数据就被污染 (共享数组暗雷)

收益: 翻页内存恒定, GC 停顿从 40ms 级降到不可测。

场景 3 · io.ReadAll 换上限读: 800MB 响应不再 OOM

抓取第三方接口, 响应体大小不可控, io.ReadAll 一路翻倍峰值≈2×终值:

// 事故: 256MB 容器抓到 800MB 响应, 直接 OOMKilled
const maxBody = 64 << 20                          // 64MB: 按业务最大合法响应定
var buf bytes.Buffer
buf.Grow(1 << 20)                                   // 预热 1MB, 减少翻倍次数
n, _ := io.CopyN(&buf, resp.Body, maxBody+1)       // 多读 1 字节探测超限
if n > maxBody {
    return nil, fmt.Errorf("body exceeds %d bytes", maxBody) // 熔断
}
// 未超限: buf.Bytes() 就是完整数据, 峰值内存 = 实际大小 + 1MB

场景 4 · 批量 insert 分批: copy 出独立切片防复用改写

rows 来自 sync.Pool 缓冲, 异步写库还没落, 缓冲已被下轮复用填充 —— 数据悄悄串单:

func insertAll(ctx context.Context, rows []Row) error {
    const batch = 500
    for start := 0; start < len(rows); start += batch {
        end := min(start+batch, len(rows))
        chunk := rows[start:end]
        own := make([]Row, len(chunk))              // 拷独立副本: 切断与池化缓冲的共享
        copy(own, chunk)                                // 池子复用会改写底层, 异步侧还拿着旧引用
        if err := db.InsertBatch(ctx, own); err != nil {
            return fmt.Errorf("batch %d-%d: %w", start, end, err)
        }
    }
    return nil
}

场景 5 · []byte→string 零拷贝: unsafe 的生产使用守则

高频路径上 strconv/日志拼接 12% CPU 花在无谓拷贝; unsafe 能救但要立规矩:

// 高频日志路径: []byte(string) 每次全量拷贝, profile 里 12% 在转换
func unsafeString(b []byte) string {
    return *(*string)(unsafe.Pointer(&b))       // 零拷贝: string 头直接盖在 slice 头上
}
// 铁律 1: 返回值生命周期内 b 不得被修改 (string 不可变契约被打破 = 数据竞争)
// 铁律 2: b 之后被 append 搬家没关系, 但底层数组不能被复用写入
// 生产流程: go test -race 全绿 + 压测对比 + 注释写明约束与评审人
// 不确定就别用: strings.Builder / bytes.Buffer 池化足够覆盖 90% 场景

场景 6 · DB 行集投影 DTO: 一次遍历 + 上限预分配

从 []Row 投影 []DTO, 往往比数据本身还高频; 遍历次数和分配次数都要抠:

func toDTOs(rows []Row) []DTO {
    out := make([]DTO, 0, len(rows))                // 上限预分配: 一次到位 0 扩容
    for _, r := range rows {
        out = append(out, DTO{
            ID:    r.ID,
            Name:  r.Name,
            State: stateName(r.State),                // 枚举码翻译在投影层一次做完
        })
    }
    return out                                      // rows 为空时返回 [] 而非 null, 前端少判空
}

场景 7 · 固定窗口环形缓冲: 满后原地覆盖零分配

监控滑窗只要最近 512 个点, append 版每轮都白扔旧数据给 GC:

type Window struct {
    buf  []float64                                // 固定容量 512: 满后环形覆盖
    head int                                      // 下一个写入位
}
func NewWindow(n int) *Window {
    return &Window{buf: make([]float64, 0, n)}   // len 从 0 长到 cap
}
func (w *Window) Push(v float64) {
    if len(w.buf) < cap(w.buf) {
        w.buf = append(w.buf, v)                 // 未满: 正常增长
        return
    }
    w.buf[w.head] = v                                  // 已满: 原地覆盖, 永零分配
    w.head = (w.head + 1) % cap(w.buf)              // 环形推进
}

场景 8 · 流式聚合: append(data, chunk...) 预估容量

分片下载聚合, 盲 append 会经历 log2(总大小) 次搬家; 按元数据预估一步到位:

func collect(ch <-chan Chunk) []byte {
    out := make([]byte, 0, estimate())               // 按文件大小预估, 偏差 20% 内都赚
    for c := range ch {
        out = append(out, c...)                     // cap 够就纯 memcpy; 不够一次搬家
    }
    return out                                       // 预估失败也只是多一次拷贝, 不是错误
}
func estimate() int {
    if fi, err := os.Stat(path); err == nil {
        return int(fi.Size()) + 4096                // 文件大小 + 头部余量
    }
    return 1 << 20                                    // 未知: 1MB 起步
}

场景 9 · 去重保序: map 判重 + 切片保序

map 无序、set 不存在; 要"去重且保持首次出现顺序"就得双结构配合:

func dedupKeepOrder(in []string) []string {
    seen := make(map[string]struct{}, len(in)) // 上限预分配: map 也不扩容
    out := make([]string, 0, len(in))                // 最坏全保留: 按 n 预留
    for _, v := range in {
        if _, ok := seen[v]; ok {
            continue                                    // map 负责判重
        }
        seen[v] = struct{}{}
        out = append(out, v)                       // 切片负责保序 — 双结构配合
    }
    return out
}

场景 10 · 容器 OOMKilled 排查: 大切片小视图滞留 + GOMEMLIMIT

heap profile 只有 30MB, 容器却涨到 512Mi 被 OOMKill —— 滞留的引用不在 heap 常驻统计里显眼:

 # 事故: 容器 limit 512Mi, RSS 缓涨到 OOMKilled; heap profile 却只有 30MB
 # 根因: 100MB 大切片切出 1KB 视图长期持有, GC 无法回收底层数组
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: api
          resources:
            requests: { memory: "384Mi" }
            limits:   { memory: "512Mi" }
          env:
            - name: GOMEMLIMIT    # Go 1.19+: 让 GC 看见容器边界
              value: "450MiB"
            - name: GOGC
              value: "100"
 # 代码侧正解: 视图要独立存活时, copy 出小片再弃大数组
 # view := make([]byte, 1024); copy(view, big[:1024]); big = nil

改完 RSS 稳在 60Mi; GOMEMLIMIT 只是止血带, 根治还得砍掉滞留引用。