在 Go 语言中，并不存在像 JavaCollection Framework那样完整、统一的集合类体系。相反，Go 选择了一条更克制、更贴近底层的数据结构路线：通过少量内建类型，配合明确的语义约束，支撑绝大多数工程场景。
这种设计取向，深刻影响了 Go 程序在性能、并发模型以及代码可维护性上的表现。
本文将从集合类型全景、使用模式、并发语义与架构建议四个层面，对 Go 的集合体系进行系统梳理。
一、Go 的集合观：少而精，而非“大而全”
Go 官方只提供了三种核心集合能力：
| 类型 | 本质 | 是否内建 |
|---|---|---|
| array | 定长连续内存 | 是 |
| slice | 动态数组 | 是 |
| map | 哈希表 | 是 |
没有：
List
Set
Queue
Stack
这些能力并非缺失，而是通过组合与约定实现。
Go 的集合哲学是：
“用最小抽象，解决最大问题。”
二、Array：存在感极低，但并非无用
var a [3]int
特性
长度是类型的一部分
栈分配（小数组）
值语义，拷贝成本高
工程定位
❌ 业务代码中极少使用
✅ 协议结构、定长数据、性能敏感场景
✅ 与 C / 底层系统交互
在工程实践中，array 更像是一种“内存布局工具”，而非通用集合。
三、Slice：Go 中真正的“主力集合”
1. Slice 的本质
type slice struct { ptr *T len int cap int }
指向底层数组
共享内存
动态扩容
2. 基础使用
s := make([]int, 0, 16)
s = append(s, 1, 2, 3)
3. 工程级注意点
（1）切片共享问题
a := []int{1, 2, 3}
b := a[:2] b[0] = 100
a也会被修改。
👉在边界处必须 copy
b := append([]int(nil), a[:2]...)
（2）扩容与性能
扩容是倍增策略
会产生内存拷贝
高频 append 建议提前
cap
make([]T, 0, expectedSize)
4. Slice 的工程定位
| 场景 | 适合度 |
|---|---|
| 顺序数据 | ★★★★★ |
| 批量返回 | ★★★★★ |
| API 边界 | ★★★★★ |
| 高并发共享 | ★☆☆☆☆ |
slice 是数据载体，不是并发容器。
四、Map：Go 中唯一的关联型集合
1. Map 的本质
map[K]V
哈希表
引用语义
无序
非并发安全
2. 常见模式
（1）字典 / 索引
userByID := map[int64]*User{}
（2）计数器
counter[k]++
（3）分组（Group By）
groups[key] = append(groups[key], item)
3. Set 的实现方式
set := map[string]struct{}{} set["a"] = struct{}{}struct{}零内存语义清晰
性能优
4. 并发问题（必须重视）
map禁止并发读写
违反直接 panic
工程解法：
sync.Mutex / RWMutexsync.Map（仅限高读低写）
map 的并发语义，必须通过“封装”解决，而不是靠约定。
五、组合出来的“集合类型”
Go 的设计鼓励你用组合，而不是继承。
1. Queue / Stack
type Stack[T any]
struct { data []T }
slice + 约定
无隐藏行为
易于审计
2. 有序 Map
keys []string data map[string]Value
map 负责查找
slice 负责顺序
六、与 Java 集合体系的根本差异
| 维度 | Go | Java |
|---|---|---|
| 集合层级 | 极简 | 庞大 |
| 抽象方式 | 组合 | 继承 |
| 并发语义 | 显式 | 容器内置 |
| 性能控制 | 开发者主导 | 框架主导 |
Go 不试图“保护你”，而是要求你对数据结构负责。
七、架构级建议（关键）
集合不要跨层共享
尤其是 map / slice
对外接口返回 slice，内部可用 map
并发集合必须封装在结构体内
不要在领域模型中暴露 map
容量是性能设计的一部分
八、结语
Go 的集合设计并不“炫技”，但极其务实。
它迫使工程师直面几个问题：
数据是否共享？
是否并发？
谁拥有修改权？
生命周期在哪里？
这些问题，本就不该被集合框架替你隐藏。
