Counter不支持流式处理，需分块读取并清洗文本后调用update；应避免全量most_common导致内存峰值，可用堆维护top_n；多进程须独立Counter再合并；IO和正则常是瓶颈，建议缓存结果。
Counter 本身不支持流式处理，大数据必须分块读取
直接把几GB的文本 read() 进内存再传给 Counter，几乎必然触发 MemoryError。Counter 的构造函数会一次性接收整个可迭代对象，它不负责分片或懒加载——这得你来控制。
正确做法是逐行或按固定大小块读取，每次只喂给 Counter 一部分数据：
- 用
with open(...)打开文件，配合for line in f:逐行处理（适合按行分隔的语料） - 对超长单行文本，改用
f.read(chunk_size)分块，再用正则或str.split()拆词 - 每批词列表调用
counter.update(word_list)，而不是重建新Counter
预处理不彻底会导致词频虚高，尤其标点和大小写
Counter 对字符串完全敏感："Hello"、"hello"、"hello." 全算不同词。不做清洗，统计结果基本不可用。
推荐在分块读取时同步做轻量清洗：
立即学习“Python免费学习笔记（深入）”；
- 用
line.lower()统一小写 - 用
re.findall(r'\b[a-zA-Z]+\b', line)提取纯字母词（跳过数字、标点、中英文混排） - 避免用
string.punctuation逐字符替换——对大文件性能差；正则一次提取更稳
如果需保留数字或特定符号（如“C++”、“APIs”），正则模式要相应调整，比如 r'\b[a-zA-Z+]+\b'。
top_n 需求强烈时，别等全部统计完再排序
全量词表可能达千万级，调用 counter.most_common(n) 前，Counter 内部会先构建完整键值对列表，内存峰值翻倍。对内存紧张场景很危险。
更稳妥的方式是边统计边维护一个固定大小的堆：
import heapq
top_heap = []
for word, count in counter.items():
if len(top_heap) < n:
heapq.heappush(top_heap, (count, word))
elif count > top_heap[0][0]:
heapq.heapreplace(top_heap, (count, word))
# 最终 top_heap 是最小堆，逆序即 top_n
result = sorted(top_heap, key=lambda x: -x[0])
注意：heapq 比 most_common() 内存友好，但仅当明确只要前 N 名时才值得换——否则徒增复杂度。
多进程加速有陷阱：Counter 不是线程安全的
想用 multiprocessing 并行读多个文件？可以。但千万别让多个进程共用同一个 Counter 实例——它不是线程/进程安全的，会丢数或崩溃。
正确并行模式是：
- 每个子进程独立创建
Counter，处理自己分到的文件块 - 主进程收集各子进程返回的
Counter对象 - 用
sum(counters, Counter())合并（注意顺序：sum([c1,c2,c3], Counter())）
合并操作本身是 O(总词种数)，比逐个 update() 稍快，但前提是各子进程的 Counter 已完成本地聚合。
实际跑起来你会发现，瓶颈常不在 Counter 本身，而在磁盘 IO 和正则匹配速度。如果词表稳定且查询频繁，统计完存成 joblib 或 pickle 二进制文件，下次直接加载，比反复解析快一个数量级。
