预设容量的 make([]int, 0, 100) 比 []int{} 更快，因其前100次append无需扩容，避免了多次内存分配与数据拷贝；而空切片字面量每次append可能触发扩容。
为什么 make([]int, 0, 100) 比 []int{} 更快
空切片字面量 []int{} 每次 append 都可能触发底层数组扩容，导致多次内存分配和数据拷贝。而预设容量的 make([]int, 0, 100) 在前 100 次 append 中完全避免扩容。
- 扩容规则：Go 默认按 2 倍增长（小容量）或 1.25 倍（大容量），但每次复制旧数据开销不可忽视
- 若已知最终长度范围，直接用
make([]T, 0, estimatedCap)；若确定长度，用make([]T, n)更省
- 注意：容量过大浪费内存，需权衡；可通过
cap()和len()监控实际使用率
map 预分配 make(map[string]int, 1000) 真的有必要吗
是的，尤其在批量写入场景下。未指定容量的 make(map[string]int) 初始哈希桶数量极少（通常为 1 或 2），插入几十个键就可能触发 rehash，带来两次遍历旧表 + 重建新表的代价。
- Go 的 map rehash 开销显著，且会暂时阻塞写操作（虽然不锁整个 map，但当前 bucket 链会被锁）
- 预估键数后传入容量参数，如
make(map[string]int, expectedKeyCount)，能大幅减少 rehash 次数 - 注意：Go 会向上取整到 2 的幂次，所以
make(map[int64]bool, 1000)实际分配约 1024 桶，不是严格 1000 - 若键数极不确定，宁可略高估，也不要留白——
make(map[T]U, 0)和make(map[T]U)行为一致，都无预分配
delete(m, k) 后 map 内存不释放？如何真正清理
是的。delete(m, k) 只清除键值对的逻辑引用，底层哈希表结构（包括已废弃的 bucket）不会立即回收，也不会缩容。map 内存只会在 GC 扫描时，当整个 map 变成不可达对象后才释放。
- 反复增删导致 map “虚胖”（大量空 bucket 占内存）？没有内置缩容机制，只能重建：
newMap := make(map[K]V, len(oldMap)) for k, v := range oldMap { newMap[k] = v } oldMap = newMap - 若只是临时缓存，建议用带 TTL 的第三方库（如
golang-lru），或定期重建 map - 用
runtime.ReadMemStats对比Alloc和HeapAlloc，可验证是否因 map 残留导致内存持续增长
切片截断后 data[:0] 还能复用底层数组吗
可以，而且这是安全复用的推荐方式。只要原底层数组没被其他变量引用，data = data[:0] 清空长度但保留容量，后续 append 仍走原数组，避免新分配。
- 错误做法：
data = []int{}或data = nil—— 彻底丢失底层数组引用，下次append必然新分配 - 适用场景：循环中重复收集数据（如批量处理、日志缓冲），配合预分配切片效果最佳
- 风险点：若切片曾被
copy出去或传递给其他 goroutine，截断可能影响他人读取——需确保无外部强引用
