jieba处理千万级单字段文本易OOM，应避免jieba.lcut()而用生成器jieba.cut()流式分词；优先按需选用关键词提取、分块统计或批量迭代；自定义词典须在首次分词前加载并调用initialize()。
jieba 默认是内存友好型设计，但面对单字段千万级字符（比如一条超长日志、整篇PDF转文本、法律文书全文），直接调用 jieba.lcut(text) 很容易触发内存暴涨甚至 OOM。关键不是“能不能分”，而是“怎么分不崩、不慢、不出错”。
单字段超长文本会卡死或爆内存？先确认是不是真需要全量分词
很多场景下，你以为要对一整段千万字文本做分词，其实真正需要的是：关键词提取、高频词统计、或按段落/句子粒度处理。盲目全量切分既无必要，又浪费资源。
- 如果目标是提取 Top100 关键词 → 用
jieba.analyse.extract_tags()，它内部做了采样和 TF-IDF 加权，不强制加载全部切词结果 - 如果要做词频统计 → 先按标点/换行切块（如用
re.split(r'[。！？；\n]+', text)），再逐块jieba.lcut()并合并 Counter - 如果字段本质是“文档集合”（如数据库里存了 10 万条新闻正文，每条平均 500 字），那千万级是总量，不是单条 —— 应该走批量迭代，而非单次传入大字符串
jieba.cut() 和 jieba.lcut() 在长文本下的行为差异
jieba.cut() 返回生成器，jieba.lcut() 强制转成 list。千万字符下，后者会试图一次性分配几百万个字符串对象的引用，极易触发 GC 压力或内存碎片。
- ✅ 正确做法：
for word in jieba.cut(long_text, cut_all=False): process(word)—— 流式消费，内存恒定在 KB 级 - ❌ 避免：
words = jieba.lcut(long_text)—— 即使你后续只取前 100 个，也得先把全部词构造出来 - 注意：
cut_all=True模式会极大增加候选词数量（比如“南京市长江大桥”能切出十几种组合），长文本下务必禁用
自定义词典没生效？长文本下词典加载时机很关键
如果你加了 jieba.load_userdict('dict.txt')，但发现新词还是被切碎了，大概率是因为：词典是在分词开始后才加载的，而 jieba 的内部 DAG（有向无环图）和 DP（动态规划）缓存已在首次调用时初始化完毕。
- ✅ 必须在第一次调用任何分词函数前加载词典：
jieba.load_userdict('dict.txt'); jieba.initialize() - ⚠️ 不要写成：先
jieba.lcut('测试')，再load_userdict—— 后续分词仍可能忽略新词 - 词典文件本身别太大（建议 load_userdict 会阻塞数秒；超大专业词典建议拆成多个小文件 + 按需加载
性能瓶颈不在算法，而在 Python 字符串拷贝和 GC
实测发现，对 500 万字符文本，jieba.cut() 耗时约 800ms，其中 60% 花在 str.__getslice__ 和临时字符串创建上，而不是核心的 DAG 构建或 DP 计算。
- ✅ 提前做轻量清洗：用
re.sub(r'[\s\u3000]+', ' ', text)把全角空格、多换行压成单空格，减少无效字符扫描 - ✅ 禁用 HMM：长文本歧义更多，但
jieba.cut(text, HMM=False)可提速 20%~30%，代价是部分未登录词切不准（如网络新词） - ⚠️ 别用
jieba.posseg.cut()替代分词 —— 词性标注额外开销接近翻倍，且返回对象更重
真实项目里最常被忽略的一点：千万字符字段往往来自数据库 TEXT 或 JSON 字段，而 Python 的 psycopg2 或 pymysql 默认会把整个字段作为 Python str 加载进内存。与其优化分词，不如先确认——这个字段是否真的需要一次性读入？能否用游标流式读取、边读边分？
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
