Python的collections模块：那些被低估的"瑞士军刀"

写Python代码写到一定阶段，你多半会遇到这样的尴尬时刻------明明用list或dict就能实现功能，但代码写出来又臃肿又慢，性能分析工具一跑，瓶颈全暴露在那些你以为"理所当然"的操作上。这时候如果有人告诉你，标准库里有一个模块专门为这些痛点准备了解药，你大概会有种"这么好的东西怎么早没告诉我"的感觉。

collections模块就是这样一个存在。它不是什么高深莫测的黑科技，而是Python官方对内置容器类型（list、dict、tuple、set）的一系列补丁式增强，目标很朴素------让常见的数据处理场景写起来更简洁、跑起来更快。这篇文章就带你把这个模块的核心概念摸透，顺便看看工程实践里大家都是怎么用的。

全景图：collections到底解决了什么问题

在深入细节之前，先搭一个整体框架。collections模块里最常用的几个类，其实各自对应着不同的"痛点"

这张图其实就是整篇文章的骨架。每一个类都是针对内置类型某个具体短板打的补丁，理解了痛点，用法自然就顺了。

核心概念逐个拆解

namedtuple------给元组装上名字标签

普通的tuple有个尴尬之处，你写point = (3, 5)，过几天回头看代码，谁还记得第一个数是x坐标还是y坐标？只能靠猜或者翻注释。

namedtuple解决的正是这个问题。它让你像定义一个简单类一样定义字段名，但底层依然是元组，该有的不可变性和内存效率一点没丢

python 复制代码

from collections import namedtuple

Point = namedtuple('Point', ['x', 'y'])
p = Point(3, 5)
print(p.x, p.y)  # 3 5，比p[0]、p[1]直观太多

工程里最常见的用法是替代那种"返回一堆无名字段"的函数结果，比如数据库查询返回的一行记录，或者某个算法返回的坐标点集合。可读性提升不是一点半点，而且因为本质是tuple，哈希、比较、序列化这些操作全都免费继承过来。

deque------两头都快的队列

list大家都熟，但很少有人注意到它有个隐藏短板------从头部插入或删除元素时，时间复杂度是 $O(n)O(n)$ O(n)，因为后面所有元素都要往前挪一位。如果你要实现的是队列（先进先出）或者滑动窗口这类需要频繁操作两端的场景，list就成了性能杀手。

deque（发音跟"deck"一样，取自double-ended queue）就是为这个场景生的。它的两端操作都是 $O(1)O(1)$ O(1)

python 复制代码

from collections import deque

dq = deque([1, 2, 3])
dq.appendleft(0)   # O(1)，list.insert(0, 0)则是O(n)
dq.popleft()        # O(1)
dq.append(4)

有意思的是deque还有个maxlen参数，一旦设置，队列满了之后新元素进来会自动挤掉最老的那个，这个特性做滑动窗口统计 、最近N条日志缓存简直是量身定制。不过也有开发者在Stack Overflow上提到过，deque在随机访问（比如按下标取中间元素）上比list慢，因为它底层是双向链表结构而不是连续内存块，这是设计上的取舍，用的时候得挑对场景。

Counter------计数这件小事，一行搞定

统计词频、统计元素出现次数，这种需求几乎每个项目都会碰到。手写的话大概是这样

python 复制代码

counts = {}
for word in words:
    counts[word] = counts.get(word, 0) + 1

能跑，但啰嗦。Counter把这套逻辑封装成了一行

python 复制代码

from collections import Counter

counts = Counter(words)
print(counts.most_common(3))  # 直接拿到出现频率最高的3个

Counter本质上是dict的子类，只是给不存在的key返回0而不是抛KeyError，还额外提供了most_common()、支持+和-运算符做集合式的计数合并/差集运算。在日志分析、文本处理、甚至简单的AB测试统计里，Counter基本是标配工具。

defaultdict------别再写try/except了

写过Python的人大概都被这种代码烦过

python 复制代码

d = {}
if key not in d:
    d[key] = []
d[key].append(value)

无非就是想往一个"分组字典"里塞数据，但每次都要判断key存不存在，烦得不行。defaultdict直接把这个判断逻辑内置了，你只需要告诉它默认值该怎么生成

python 复制代码

from collections import defaultdict

d = defaultdict(list)
d[key].append(value)  # key不存在也不报错，自动先给个空list

这里的list不是随便写的，而是一个工厂函数 ，调用它就能得到默认值，常见的还有int（默认给0，做计数用）、set、甚至自定义的lambda。在做图的邻接表构建 、分组统计这类场景时，defaultdict能省掉大量的样板代码。

OrderedDict------顺序这件事曾经很重要

这里要讲个历史背景。Python 3.7之前，普通dict是不保证遍历顺序的（虽然CPython实现里其实已经有序，但语言规范没承诺）。OrderedDict就是那个年代专门用来保证插入顺序的字典。

Python 3.7之后，普通dict已经官方承诺保序了，所以OrderedDict在很多场景下不再是必需品。但它还留着两个独门绝技------move_to_end()方法可以把某个key挪到字典的最前或最后，这个特性配合maxlen思路，正是实现LRU缓存的经典手法

python 复制代码

from collections import OrderedDict

od = OrderedDict()
od['a'] = 1
od['b'] = 2
od.move_to_end('a')  # 'a'现在排到最后了

另外OrderedDict在相等性比较上也和普通dict不同，它比较两个OrderedDict是否相等时会连顺序一起比，这个细节在做缓存一致性校验时挺有用。

ChainMap------多个字典叠在一起查

假如你的程序里有多层配置------命令行参数、环境变量、配置文件默认值------查找一个配置项时优先级是命令行 > 环境变量 > 默认值。传统做法是把三个字典合并成一个新字典，但这样每次配置变了就得重新合并一次，挺浪费。

ChainMap的思路是不复制数据，只是叠加视图

python 复制代码

from collections import ChainMap

cmd_args = {'verbose': True}
env_vars = {'debug': False}
defaults = {'debug': True, 'verbose': False}

config = ChainMap(cmd_args, env_vars, defaults)
print(config['verbose'])  # True，从cmd_args里查到的
print(config['debug'])    # False，cmd_args没有，往后找到env_vars

查找时按顺序依次往后找，第一个匹配到就返回，底层字典的任何改动都会实时反映在ChainMap上，这一点在做多层配置管理时特别省心。

工程实践里，这些工具到底怎么落地

把概念讲完了，实际项目里怎么组合用才是关键。下面这个表格总结几个典型场景

业务场景	首选工具	为什么选它
日志高频写入的滑动窗口统计	`deque(maxlen=N)`	自动淘汰旧数据，O(1)插入
词频/事件频率统计	`Counter`	内置`most_common()`，少写循环
图算法的邻接表构建	`defaultdict(list)`	免去存在性判断的样板代码
LRU缓存实现	`OrderedDict`	`move_to_end()`天然适配淘汰策略
多层级配置合并查询	`ChainMap`	零拷贝叠加，配置改动实时生效
函数返回结构化数据	`namedtuple`	兼顾可读性和元组的轻量高效

工程实践里还有个容易被忽略的点------这些容器类型大多是C语言实现（deque、OrderedDict底层都有C加速），所以除了写起来省代码，跑起来往往也比纯Python手写的等价逻辑快不少，尤其是deque在大量数据两端操作的场景下，性能差距会很明显。

还有个实战建议，很多人会把collections里的工具和itertools模块搭配用，比如用Counter统计完之后再用itertools.groupby做进一步分组处理，两者组合起来能覆盖相当大一部分数据处理需求，写出来的代码往往比纯手工循环短一半甚至更多。

写在最后

collections模块给人的感觉有点像厨房里那些专用小工具------削皮器、蒜蓉压泥器、开瓶器，单独看好像可有可无，但真正用顺手了就再也不想回到"一把菜刀走天下"的日子。namedtuple让数据结构自带说明书，deque让队列操作飞起来，Counter把计数这种脏活累活压缩成一行代码，defaultdict和ChainMap则分别解决了字典初始化和多层查找的痛点。

下次写代码遇到"这个逻辑好像有点啰嗦"的直觉时，不妨先想想collections里是不是已经有现成的答案，很多时候真的有。

参考资料

Python官方文档. collections --- Container datatypes . docs.python.org/3/library/c...
OneUptime Blog. How to Use collections Module in Python . oneuptime.com/blog/post/2...
Real Python. collections | Python Standard Library . realpython.com/ref/stdlib/...
Medium (@oz3dprinter). Mastering Python's collections: Beyond Lists and Dicts for High-Performance Systems . medium.com/@oz3dprinte...
Stack Overflow. Why is collections.deque slower than collections.defaultdict? . stackoverflow.com/questions/6...