Go 准备把泛型集合放进标准库：来得晚，但兼容成本更值得看
作者：林岚｜OC 开发者生态编辑
Go Collections 工作组公布了一组面向 Go 1.28 的 集合类型提案，准备为标准库补上哈希映射、集合、有序映射和新版泛型堆等常用数据结构。它们目前仍处于提案阶段，不是已经确定发布的 Go 1.28 功能。
一句话结论：Go 终于有条件把 Set 等集合做得像标准库，但真正困难的不是写一棵树或包一层 map，而是确定一套可能要兼容十几年的方法名、返回值和性能承诺。
Go 长期依赖内置 slice 和 map。开发者通常用 map[T]struct{} 表示集合，遇到有序映射、自定义等价关系或类型安全优先队列时，再选择第三方库或自己实现。这样简单，却让不同项目重复发明 API，也很难让公共接口统一使用一种集合类型。
直到 Go 1.18 加入泛型、Go 1.23 加入迭代器，库类型才有机会获得接近内置类型的使用体验。工作组计划中的 container/set.Set[T] 直接以 map[T]struct{} 表示普通集合；container/hash.Map 和 hash.Set 支持自定义哈希及等价规则；container/ordered.Map 面向范围查询；container/heap/v2 则替代当前较难使用的非泛型堆接口。
提案最有意思的部分不是类型数量，而是它刻意保留的克制。Union、Intersection 等集合代数提供返回新集合的版本，也提供以 With 结尾的原地修改版本，避免像 math/big.Int 那样让调用者猜参数是否会被改写。Map.Set 和 Delete 返回旧值及布尔标记，减少重复查找。
工作组也没有急着公开一套“大一统”集合接口。不同具体集合的 Union(S) S 存在二元方法兼容问题，需要递归泛型约束才能抽象。当前 _AbstractCollection、_AbstractMap 和 _AbstractSet 只是未导出的测试约束，用来检查 API 一致性，等获得实践经验后再决定是否公开。
类似地，Subset 被排除在核心接口之外，因为通用实现通常仍是 O(n)，不值得给每种实现增加永久负担；DeleteFunc 被保留，是因为树结构若逐个删除可能从 O(n) 退化到 O(n log n)。这正是标准库设计和普通工具库的区别：每增加一个方便方法，也增加一项长期维护义务。
关键事实
- 状态：面向 Go 1.28 的伞形提案，尚未等同于正式发布
- 拟新增类型：自定义哈希 Map/Set、普通 Set、有序 Map、泛型 Heap
- 语言基础：Go 1.18 泛型与 Go 1.23 迭代器
- 设计重点：统一习惯、明确变更语义，同时避免过早公开庞大抽象接口
OC 判断
来得晚不一定是坏事。Go 如果在泛型和迭代器之前推出集合框架，很可能留下大量 interface{}、类型断言和难以替换的旧 API。现在的问题是提案是否足够小、能否与内置 map 自然共存，而不是标准库能不能追上其他语言的数据结构清单。
为什么重要
- 对开发者：短期内不要把提案 API 当成稳定依赖，但可以参与具体 issue 的兼容性讨论。
- 对库作者：标准 Set 可能减少公共 API 中
map[T]struct{}的歧义，并统一迭代方式。 - 对 Go 生态：一旦进入标准库，第三方集合库的价值会转向专业结构和性能优化。
评论
围绕这篇文章补充信息、提出问题或分享观察。