预分配需按场景选择：需逐步写入用make([]t, 0, n)，需立即零值用make([]t, n)；map预分配hint向上取整到2的幂，过大浪费内存，过小引发多次rehash。
预分配不是“写了就快”，而是“写对了才省事”。盲目用 make 反而拖慢启动、浪费内存、掩盖逃逸问题。
什么时候该用 make([]T, 0, n) 而不是 make([]T, n)
关键在「是否需要立刻填满零值」。前者只预留底层数组空间，不写任何字节；后者会立刻分配并填充 n 个零值，多一次全量内存写操作。
- HTTP body 解析、JSON 反序列化、日志拼接等——数据是逐步写入的，用
make([]byte, 0, estimatedSize)更合适 -
buf := make([]byte, n); _ = io.ReadFull(r, buf)是错误示范：make已分配一份内存，io.ReadFull内部可能再 realloc，等于白干两次 - 正确做法是
buf := make([]byte, 0, n); buf, _ = io.ReadAll(r)，或配合bytes.Buffer.Grow(n)
make(map[K]V, n) 的 hint 到底怎么影响底层 bucket 分配
Go 不会按 n 精确分配 n 个 slot，而是向上取整到 2 的幂次作为初始 bucket 数。比如 make(map[string]int, 100) 实际分配的是 128 个 slot（1 个 bucket）；make(map[string]int, 0) 显式指定 hint=0，则只分配 1 个最小 bucket（8 个 slot），比默认创建更省内存。
- hint 过大（如
make(map[string]*User, 10000)实际只存 50 个）：多占内存、GC 扫描更多指针、map 不自动缩容，删光后内存也不还 - hint 过小（如预估 100，实际插入 1000）：触发多次扩容，每次都要 rehash 全量已有 key，开销远超一次预分配
- 键分布严重倾斜（大量哈希冲突）时，hint 几乎无效，性能瓶颈在哈希质量，不在初始容量
切片扩容策略和真实代价在哪
每次 append 触发扩容，都要 malloc 新数组 + copy 旧数据 + 释放旧内存——三步全在堆上，且旧数组可能滞留到下次 GC 才回收。
- 容量 cap → cap * 2）
- 容量 ≥ 1024：每次 +25%（
cap → cap + cap/4） - 别写
s := make([]int, len(src)); for _, v := range src { s = append(s, v*2) }——这等于先填满再扩，白 copy 一次 - 预分配后仍要用
append，不能直接下标赋值；否则越界 panic，且len不更新
真正容易被忽略的是：预分配是否匹配你的数据生命周期。如果 slice 或 map 只在函数内短时存在，且长度波动大、无法可靠估算，硬加 make 可能只是让 profile 图上多出几条没意义的内存分配线。先跑 go tool pprof -alloc_objects 看真实分配热点，再决定动不动 make。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
