01
批量查询与结果收集
- 业务例子
- 分页读取商品或订单，把本页结果转换后追加到结果 Slice，最终批量写库或返回接口。
- 为什么适合
- 数据按顺序产生并连续访问，Slice 的缓存局部性好；预估数量后可预分配容量，减少扩容和复制。
- 注意
- 数据量不受控时不要无限 append，应分页处理、流式消费或设置上限。
Application Scenarios
应用场景：这个知识点实际用在哪里
Slice 适合处理长度会变化、但仍希望连续存储和高效顺序访问的数据。工程里真正需要关注的不是会不会 append，而是能否预估容量、是否共享底层数组，以及对象是否会被意外长期引用。
02
预分配批处理缓冲区
- 业务例子
- 已知最多处理 1000 个 ID 时，用 make([]string, 0, 1000) 建立长度为 0、容量为 1000 的结果容器。
- 为什么适合
- 保留 append 的自然写法，同时减少重复分配；len=0 也避免把尚未写入的位置误当成有效数据。
- 注意
- 容量估计远大于实际值会浪费内存，尤其是元素较大或请求并发很高时。
03
原地过滤与复用内存
- 业务例子
- 使用 out := items[:0]，把符合条件的元素 append 回 out，避免额外创建同等大小的新 Slice。
- 为什么适合
- 输入不再需要保留时，可复用同一个底层数组，降低分配次数和 GC 压力。
- 注意
- 元素含指针时应清理尾部无效槽位；其他共享该数组的 Slice 也会看到修改。
04
需要隔离的快照
- 业务例子
- 缓存配置更新前复制一份 Slice，或把大响应缓冲区中的一小段数据复制后长期保存。
- 为什么适合
- copy 或 slices.Clone 创建独立底层数组，避免调用方修改内部状态，也避免小窗口长期留住大数组。
- 注意
- 复制是 O(n) 且占额外内存，只在所有权或生命周期确实需要隔离时使用。
什么时候不应该硬用
- 长度固定且类型本身就应表达固定尺寸时，优先使用数组，例如 [32]byte 哈希值。
- 需要频繁从头部删除的长队列，不要长期依赖 s = s[1:]；考虑环形缓冲区或专用队列。
- 多个 goroutine 并发 append 同一个 Slice 不是安全操作；应加锁、分片后汇总或通过 Channel 交接。
- 需要按 key 高频查找时不要遍历 Slice 硬撑，应根据业务选择 map 或数据库索引。
面试里可以这样落地
我会先判断数据是否适合连续存储，再根据可预估数量做 make([]T, 0, n) 预分配。传递 Slice 时我会明确底层数组所有权：允许复用就原地过滤，需要隔离就 copy；对于长期保存的子 Slice，还会避免它意外留住大数组。