直接用Counter读完整文件会内存爆炸，因为open().read().split()先将整个文件加载进内存再切词，GB级文本直接触发MemoryError；应逐行或分块读取并用update()增量更新，避免一次性加载和重建字典。
为什么直接用 Counter 读完整文件会内存爆炸
超大文本（比如几 GB 的日志或语料）如果用 open().read() 或 split() 一次性加载进内存，Counter 就得先存下全部词——这往往远超可用内存。不是 Counter 有问题，而是你喂给它的数据结构太大。
真正可行的路径是：流式分块读取 → 增量统计 → 最后只保留 Top 10。
关键点：Counter 支持 .update()，可以反复喂词，不用一次性构造整个列表。
用生成器 + update() 实现低内存词频统计
核心思路是避免构建完整词列表，边读边喂给 Counter。注意分词逻辑要轻量（别用 re.findall(r'\w+', ...) 处理整行，它会生成临时列表）。
立即学习“Python免费学习笔记（深入）”；
- 按行读取，对每行用
str.split()（默认空格分割，不产生正则开销） - 过滤掉空字符串和纯标点（如
''、'.'），建议用word.isalpha()或简单长度判断 - 统一转小写（除非业务要求区分大小写）
- 每处理完 1000 行或 10MB 数据，调用一次
counter.update(word_list)，避免中间列表过大
示例片段：
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
from collections import Counter
counter = Counter()
with open('huge_file.txt', encoding='utf-8') as f:
for line in f:
words = [w.lower() for w in line.split() if w.isalpha()]
counter.update(words)
# 可选：定期裁剪，只留前 100 名，防极端偏态分布撑大 counter
if len(counter) > 1000:
counter = Counter(dict(counter.most_common(1000)))
top10 = counter.most_common(10)
遇到中文、连字符、缩写怎么办
str.split() 对中文完全失效，对 don't、state-of-the-art 也会切碎。这时候不能硬扛，得换分词策略，但必须控制开销：
- 纯英文缩写：用
re.finditer(r"[a-zA-Z]+(?:'[a-zA-Z]+)?", line)比split()更准，且是迭代器，不生成全量列表 - 中英文混合：轻量方案用
jieba.lcut()，但务必设jieba.initialize()提前加载词典，并禁用 HMM（jieba.setLogLevel(20)），否则首次调用卡顿+内存飙升 - 超大文件慎用
nltk.word_tokenize：它内部会加载庞大数据，启动慢，且默认分词结果含标点 token，需额外过滤
如果只是 Top 10，其实可以接受少量切分误差——毕竟排在第 10 的词频通常比第 1 名低一个数量级，错切几个不影响大局。
为什么 most_common(10) 在最后才调用
Counter.most_common(n) 时间复杂度是 O(N log n)，其中 N 是不同词的数量。如果你每轮都调它，等于反复对几万甚至几十万个键排序，性能雪崩。
正确做法是：全程只做 .update()，最后调一次 .most_common(10)。如果中途担心内存，就用前面提到的「定期裁剪到 1000」策略——most_common(1000) 开销远小于对 50 万词排序。
还要注意：most_common() 返回的是 list，不是新 Counter，所以不要写成 counter = counter.most_common(10)，那会丢失类型，后续无法再 .update()。
真正容易被忽略的是编码和 BOM：Windows 记事本保存的 UTF-8 文件可能带 BOM，导致第一行词变成 '\ufeffthe'，统计失真。加 encoding='utf-8-sig' 能自动剥离。
