make的第三个参数cap是底层数组总长度，非额外长度；如make([]int, 2, 4)中len=2、cap=4，append不超过4时不扩容，但直接索引a[2]会panic。
make 不是通用内存分配器，它只对 []T、map[K]V、chan T 三种类型生效；用错类型（比如 make(*int, 10)）会直接编译失败。
make([]T, len, cap) 的容量预留到底怎么算
第三个参数 cap 是底层数组的总长度，不是“额外多给的长度”。make([]int, 2, 4) 表示：切片当前长度为 2，但底层数组已分配 4 个 int 空间，后续 append 在不超过 4 时不会触发扩容。
-
len(a) == 2，cap(a) == 4，a[0]到a[1]可读写，a[2]和a[3]尚未“暴露”给切片，不能直接索引访问 -
a = append(a, 1, 2)后仍不扩容，因为 2+2 ≤ 4；但再append(a, 3)就会分配新底层数组 - 错误写法：
make([]int, 4, 2)编译报错 ——cap必须 ≥len
map 和 chan 的 capacity 参数其实是提示值，不是硬约束
make(map[int]string, 100) 中的 100 是运行时用于预估哈希桶数量的 hint，不是“最多存 100 个键”。实际插入 101 个键完全合法，只是可能提前触发一次桶扩容。
-
map的 hint 影响初始内存占用和首次扩容时机，但不影响正确性或并发安全 -
chan的buffersize是硬限制：make(chan int, 5)最多缓存 5 个值，第 6 次send若无接收者就会阻塞 - 对性能敏感场景（如高频插入 map），合理 hint 可减少 rehash 次数；但过度预估（如 hint=10000 却只存 10 个）浪费内存
为什么 make 大 slice 容易 OOM，且 runtime.MemStats 帮不上忙
make([]byte, 1e9) 这类调用会绕过 Go 堆管理器的精细控制，直接向 OS 申请连续虚拟内存页。而 runtime.MemStats 只统计 Go 自己已分配/释放的堆内存，不反映系统剩余物理内存或 cgroup 限额。
- Linux 上读
/proc/meminfo的MemAvailable是快照，make执行前可能已被其他进程占用 - Kubernetes 容器中，
MemAvailable完全无效，真正限制是cgroup v2 memory.max - 可靠做法是：启动时通过环境变量或 flag 注入最大允许字节数（如
MAX_ALLOC_BYTES=536870912），分配前做显式比较：if size > maxAllocBytes { return errors.New("allocation too large") }
真正影响性能的不是“有没有调 make”，而是 cap 预估是否贴近真实增长曲线 —— 过小导致频繁 append 扩容（复制旧数据），过大造成内存浪费甚至触发 OOM；这个平衡点必须结合业务数据分布来定，没法靠工具自动猜准。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
