多数场景下不推荐用类封装文本清洗函数，应优先使用轻量、易测试、可组合的函数；仅当强依赖外部上下文（如动态停用词、多语言分词器）时才考虑类，并将配置全收进__init__。
文本清洗函数要不要封装成类
多数场景下，不推荐用类封装基础清洗逻辑。函数更轻量、易测试、方便组合，比如 clean_text() 和 normalize_whitespace() 直接 import 就能链式调用；而一旦套上类，就容易过早引入状态（如缓存正则对象、配置字段），反而让单元测试变重、pipeline 中复用变难。
只有当清洗流程强依赖外部上下文（如需动态加载停用词表、适配不同语言的分词器、或与数据库连接池协同）时，才考虑用类。此时注意把可配置项全收进 __init__，避免在 clean() 方法里硬编码路径或正则。
- 常见错误：把
re.compile(r's+')写在方法体内——每次调用都重新编译，性能掉一截 - 正确做法：提成模块级常量
WHITESPACE_PATTERN = re.compile(r's+')，或在类初始化时预编译 - 兼容性注意：python 3.12+ 对
re.Pattern类型提示更严格，别漏写Pattern[str]
正则替换该不该用 re.sub 还是 re.subn
re.sub 足够日常使用；re.subn 只在需要确认“这次清洗到底改了多少处”时才有价值，比如做数据质量审计、异常文本报警、或灰度发布时对比清洗前后差异。
工程中容易忽略的是：正则匹配失败时，re.sub 返回原字符串，但 re.subn 返回 (text, 0) ——这个 0 很容易被当成布尔 False 误判为“执行失败”，导致监控误报。
立即学习“Python免费学习笔记（深入）”；
- 典型误用：
if not re.subn(pattern, '', text)[1]: log.warn("no match!")——其实只是没匹配到，不是出错 - 安全写法：显式解包并判断
count是否大于 0，或直接用bool(re.search(pattern, text))做前置检查 - 性能影响：两者底层开销几乎一致，但
re.subn多一次元组构造，高频清洗场景可忽略
清洗后要不要保留原始文本字段
必须保留。哪怕业务方说“只要干净文本”，上线后大概率会遇到溯源、bad case 分析、AB 测试比对等需求，没有原始字段就得翻日志、查上游、甚至重跑 pipeline。
工程实践里，统一加前缀比用 suffix 更稳妥，比如 raw_text 和 cleaned_text，而不是 text_clean 和 text——后者在 DataFrame 列排序或 autocomplete 时容易混淆。
- 常见错误：清洗函数直接修改传入的
dict或pandas.Series，导致原始数据被污染 - 正确做法：默认返回新字典/新 Series；若真要 in-place，加参数
inplace=False并文档注明风险 - 内存提醒：如果原始文本超长（如整篇 PDF ocr 结果），又只需部分清洗结果，考虑用生成器 yield 清洗片段，而非一次性 load 全量
空格、换行、零宽字符怎么才算“真正清干净”
只用 str.strip() 和 re.sub(r's+', ' ', ...) 远不够。Unicode 里有十多种空格类字符（如 u200b 零宽空格、u00a0 不间断空格）、还有段落分隔符 u2029，这些在 s 默认模式下不匹配，除非加 re.UNICODE 标志或显式枚举。
更隐蔽的是控制字符（如 x00–x1f），某些爬虫响应头缺失时会混进文本，导致后续 nlp 模型 tokenizer 报错或静默截断。
- 推荐组合：
text.translate(str.maketrans('', '', 'x00-x1fu200bu200cu200du2060ufeff'))清控制符和零宽 - 再补一句：
re.sub(r'[u00a0u1680u2000-u200bu2028u2029u202fu205fu3000]', ' ', text)统一为空格 - 验证技巧：用
repr(text)快速看不可见字符；生产环境可加断言assert 'x00' not in text防止脏数据穿透
真正麻烦的从来不是“怎么删”，而是删完之后没人校验是否删对了——尤其跨语言文本里，有些看似空格的其实是阿拉伯语连字分隔符，删了反而破坏语义。这类边界得靠真实语料反馈，不是正则能穷尽的。