预分配容量是高频追加场景下的必选项；make([]t, 0, n) 直接预留n空间，后续n次append零拷贝、零分配，而make([]t, 0)初始cap=0，首次append即触发扩容，小数据量也可能因倍增策略多次malloc+memcpy，性能断崖式下降。
预分配容量不是“可选优化”，而是高频追加场景下的必选项；不设 cap 的 slice 在循环中追加固定数量元素，大概率触发多次底层数组重分配与拷贝，性能损耗会随调用频次指数级放大。
为什么 make([]T, 0, N) 比 make([]T, 0) 快得多
Go 的 append() 在 len == cap 时必须扩容：分配新数组 + 逐个复制原元素 + 追加新元素。而 make([]T, 0) 创建的是 cap == 0 的 slice，第一次 append 就要分配；make([]T, 0, N) 则直接预留 N 个元素空间，后续 N 次 append 全部走指针偏移，零拷贝、零分配。
- 常见错误写法：
bars := make([]Bar, 0)→ 1000 次追加可能触发约 10 次扩容，累计拷贝超 5000 个元素 - 正确写法：
bars := make([]Bar, 0, len(foos))→ 1000 次追加仅 1 次分配，0 次拷贝 - 实测对比（100 万元素）：
make([]int, 0)耗时约 23ms，make([]int, 0, n)仅约 8ms
容量预估不准时，宁高勿低
扩容策略本身有代价：cap ≤ 1024 时翻倍，>1024 时 ×1.25。这意味着从 1000 扩到 2000 是一次操作，但从 1000 扩到 1250 再扩到 1562…最终可能多触发 2–3 次分配。所以略高估比低估更安全。
- HTTP query 参数解析：最多 20 个键值对 → 用
make([]Param, 0, 24) - 数据库批量查询：预估 95% 场景 ≤ 500 行 → 用
make([]*User, 0, 600) - 切忌用
make([]T, 0, 0)或var s []T启动循环追加逻辑
静态数据结构，直接字面量初始化更优
如果每轮写入的数据长度和内容完全确定（如 OpenGL 渲染中每个 sprite 固定 12 个 float32 坐标），append() 本身就是冗余操作——编译期就能确定内存布局，运行时应直接初始化。
- 避免：
vertexInfo.Translations = append(vertexInfo.Translations, x, y, 0)×4 - 推荐：
Translations: []float32{x, y, 0, x, y, 0, x, y, 0, x, y, 0} - 优势：无分支判断、无扩容检查、无中间变量、内存连续；在每帧渲染数百次的场景下，FPS 提升可达 4–7 帧
真正容易被忽略的点是：即使只追加 4 个元素，若 slice 初始 cap == 0，也可能触发 2–3 次扩容——因为 Go 不会为 4 个元素一次性分配 4 空间，而是按倍增策略走 0→1→2→4，每次都是独立 malloc + memcpy。高频场景下，这些“微小开销”才是压垮性能的最后一根稻草。
