container标准库提供heap、list、ring三个底层实现而非泛型容器：list是需类型断言的双向链表实现；heap是需自定义类型的堆化切片；ring是固定长度的单向循环结构；三者均不支持并发安全，须手动加锁。
标准库
不提供“内置集合类型”，它只提供三个可复用的底层数据结构实现：
、
和
。它们不是开箱即用的泛型容器，而是需要你配合接口约定和手动管理的工具型组件。
为什么 container/list 不是“链表类型”而是“链表实现”
是一个双向链表的具体实现，但它不封装类型，所有值都存为
。这意味着：
- 插入时自动装箱，取出时必须类型断言（比如
）
- 没有编译期类型检查，运行时 panic 风险高
- 适合值类型小、操作频繁（如 LRU 缓存淘汰队列）、且类型混杂的场景
- 不适合替代切片做顺序访问——随机访问是 O(n)，而
是 O(1)
常见错误现象：
直接当
用却没断言，导致 panic:
container/heap 的本质是“堆化切片”而非“堆类型”
没有
结构体，它只提供一组函数（
、
、
）作用于满足
的任意切片。关键点：
- 必须自己定义类型并实现 5 个方法：
、
、
、
、
-
和
方法接收的是
指针，否则修改不会反映到底层切片
-
必须先取末尾元素再截断切片（顺序反了会丢数据）
- 最小堆 / 最大堆仅由
返回值决定，无需改其他逻辑
示例陷阱代码（错）：
container/ring 是唯一真正“无头无尾”的环形结构
和前两者完全不同：它不抽象为“集合”，而是一个单向循环节点
，每个节点自带
和
。
- 初始化后长度固定（
创建 n 个节点），不能动态增删
-
是安全遍历方式，避免手动 next 走飞；但要注意它不保证执行顺序（取决于起始点）
- 典型适用场景：固定缓冲区轮转（如日志行缓存）、游戏 tick 循环、令牌桶限流中的 slot 管理
- 没有
方法，得自己计数或遍历一圈才能知道有效数据量
性能影响：
的内存局部性比
好（节点连续分配），但比切片差；它的优势不在速度，而在语义明确的循环语义。
Python3.6标准库参考手册（PDF版）
Python3.6标准库参考手册（PDF版）
下载
立即学习
“
go语言免费学习笔记（深入）
”；
最常被忽略的一点：这三个包全都不支持并发安全——任何多 goroutine 读写都必须自行加锁，
或
不能省。
containerheaplistringcontainer/listinterface{}e.Value.(string)[]Te.Valueintinterface {} is string, not intcontainer/heapHeapInitPushPopheap.InterfaceLenLessSwapPushPopPushPop*YourTypePopLess(i,j)func (h *IntHeap) Pop() interface{} {
*h = (*h)[:len(*h)-1] // 错！先截断再取，取不到原末尾
return (*h)[len(*h)-1]
}container/ring*RingNext()Do()ring.New(n)Do()Len()ringlistsync.Mutexsync.RWMutex