字符串与文本处理中的数据操作：从编码清洗到正则工程化

1. 项目概述：字符串与文本处理中的数据操作，远不止“切片拼接”那么简单

你打开一份爬虫抓回来的电商商品页HTML，里面混着大量空格、换行、不可见Unicode字符和嵌套的HTML标签；你收到销售同事发来的Excel表格，客户姓名列里夹着“张三（VIP）”“李四【重点】”“王五(待跟进)”；你调试一个日志分析脚本，发现时间戳格式在不同服务器上分别是"2024-03-15T08:23:41Z"和"15/Mar/2024:08:23:41 +0000"……这些场景，没有一个能靠str.replace()或split()三两下搞定。字符串与文本处理中的数据操作（Data Manipulation in String and Text Processing），本质上是一场与“非结构化噪声”的持续对抗——它不是编程入门的附属练习，而是数据工程师、分析师、后端开发甚至内容运营人员每天真实面对的硬核战场。我做过七年的数据管道搭建，亲手写过200+个文本清洗模块，最深的体会是：90%的数据质量问题，根源不在数据库或ETL工具，而在第一行text = input_string.strip()之后的那几十行逻辑里。这部分工作不炫技，但决定整个数据链路的可信度。它要求你既懂字符编码的底层规则（比如为什么'café'.encode('utf-8')是5字节而'cafe'.encode('ascii')是4字节），又得会用正则表达式精准外科手术式地剥离干扰（比如用r'\s+(?=\w)'只删除单词前的多余空格，保留缩写如“I’m”里的撇号）；既要能处理GB2312中文乱码这种历史遗留问题，也要能解析JSON-LD这类现代语义标记。它不依赖框架，却比任何框架都更考验基本功。如果你正在被脏数据拖慢分析节奏，或者写的清洗脚本总在新数据源上崩溃，那么这一部分绝不是“学完就扔”的语法糖，而是你技术栈里最该打磨的那把瑞士军刀。

2. 核心思路拆解：为什么传统字符串操作在真实场景中必然失效？

2.1 从“理想模型”到“现实泥潭”的断层

教科书里讲字符串操作，常默认输入是“干净”的：ASCII字符、无嵌套结构、编码统一、分隔符明确。但现实世界的数据源像一锅大杂烩。我们团队去年接手一个政府公开数据集，CSV文件标称UTF-8，实际前10万行是UTF-8，中间2万行因某次Excel另存为操作变成了GBK，最后5万行又混入了Windows-1252编码的特殊符号。如果按传统思路先open(file, 'r', encoding='utf-8')再处理，程序会在第100001行直接抛出UnicodeDecodeError——这不是代码bug，而是对数据本质的误判。真正的数据操作，第一步永远不是写逻辑，而是做“数据考古”：用chardet库探测真实编码，用unicodedata.category()分析每个字符的Unicode类别（是字母、标点、控制符还是组合符），用repr()打印原始字节流看不可见字符。我见过太多人跳过这步，结果花三天调一个正则，最后发现问题是\u200e（左向隐式字符）在肉眼不可见处干扰了匹配。

2.2 正则表达式的双刃剑：何时该用，何时必须弃用？

正则是文本处理的核武器，但滥用它就像用高射炮打蚊子。举个典型反例：有人想提取一段HTML中的所有链接，写r'<a href="(.*?)">'。这在简单测试页上能跑通，但遇到<a href="https://example.com?q=a&b=c">时，.*?会贪婪匹配到第一个>，导致q=a&b=c被截断。更糟的是，如果页面里有注释<!-- <a href="fake"> -->，这个正则会错误匹配注释里的伪标签。专业做法是：结构化文本（HTML/XML/JSON）必须用专用解析器（BeautifulSoup、lxml、json.loads），正则只用于处理“已知结构、未知内容”的纯文本片段。比如清洗用户评论，我们可以先用lxml提取<div class="comment-text">节点内容，再对纯文本内容用正则清理表情符号（r'[\U0001F600-\U0001F64F\U0001F300-\U0001F5FF]'）或电话号码（r'1[3-9]\d{9}'）。这个原则救过我们至少5个项目——当正则开始嵌套三层以上或出现(?<!...)这种负向先行断言时，就是该重构架构的明确信号。

2.3 编码与解码：那些让你深夜加班的隐形炸弹

字符编码问题不是玄学，而是有迹可循的工程问题。关键在于理解“字节序列→字符→字符串”的转换链条。举个实操案例：处理微信公众号导出的CSV。导出文件用记事本打开显示正常，但Python读取时报错。用hexdump -C file.csv | head看前几个字节，发现是ef bb bf——这是UTF-8 BOM（字节顺序标记）。很多老系统生成的UTF-8文件会带BOM，而Python的csv.reader默认不处理它，导致第一列字段名变成'\ufeffid'。解决方案不是粗暴strip('\ufeff')，而是用open(file, 'r', encoding='utf-8-sig')——utf-8-sig编码器会自动忽略BOM。另一个高频坑：中文路径名。在Windows上用os.listdir()获取文件名，如果路径含中文，返回的可能是b'\xd6\xd0\xce\xc4.txt'字节串而非字符串。此时不能直接.decode('utf-8')，因为Windows默认用GBK编码路径。正确姿势是os.fsdecode()，它会根据系统API返回正确的字符串。这些细节看似琐碎，但累计起来，占了我们文本处理类故障的60%以上。

2.4 性能陷阱：为什么你的清洗脚本在10万行数据上慢如蜗牛？

字符串操作的性能瓶颈常被低估。比如一个常见需求：给每行文本添加行号前缀。新手会写：

lines = text.split('\n') result = [] for i, line in enumerate(lines): result.append(f"{i+1:04d} {line}") output = '\n'.join(result)

这在1万行内没问题，但到100万行时，内存占用会飙升——split()生成百万个字符串对象，join()又需要一次性分配巨大内存块。专业方案是流式处理：

def add_line_numbers(file_path): with open(file_path, 'r', encoding='utf-8') as f: for i, line in enumerate(f, 1): yield f"{i:04d} {line.rstrip('\n')}\n" # 使用时：for processed_line in add_line_numbers('big_file.txt'): print(processed_line)

用生成器避免内存爆炸，且enumerate(f)直接按行迭代，不加载全文。再比如批量替换，str.replace()对单次替换高效，但10个替换规则链式调用（s.replace(a,b).replace(c,d)...）会产生9个中间字符串。改用re.sub()配合预编译的正则模式，或构建映射字典+str.translate()（对单字符替换最快），性能提升可达百倍。这些优化不是“过度设计”，而是处理TB级日志的必备技能。

3. 核心细节解析与实操要点：从字符原子到语义单元的逐层处理

3.1 字符级清洗：看不见的敌人比看得见的更危险

真实文本里的“脏”，70%来自不可见字符。除了常见的\n、\t、\r，还有：

• 零宽空格（ZWSP）：\u200b，用于网页排版防止单词断行，但在数据中会导致"hello\u200bworld"无法匹配"helloworld"
• 软连字符（SHY）：\u00ad，显示时仅在断行处出现，但存储在字符串中影响长度计算
• Unicode方向标记：\u202a（左向嵌入）、\u202c（弹出方向格式），常出现在多语言混合文本中

实操方案：我们建立了一套标准化的“字符净化”函数：

import unicodedata import re def clean_invisible_chars(text): # 步骤1：标准化Unicode（NFKC形式，合并兼容字符） text = unicodedata.normalize('NFKC', text) # 步骤2：移除控制字符（除制表、换行、回车外） text = re.sub(r'[\x00-\x08\x0b\x0c\x0e-\x1f\x7f-\x9f]', '', text) # 步骤3：移除零宽字符（ZWSP, ZWNJ, ZWJ等） text = re.sub(r'[\u200b-\u200f\u202a-\u202e\u2060-\u2064\u2066-\u2069]', '', text) # 步骤4：折叠连续空白为单个空格（保留段落结构） text = re.sub(r'[ \t\u00a0\u2000-\u200a]+', ' ', text) return text.strip() # 验证效果 test_str = "Hello\u200bWorld\u200cTest\n\n \t " print(repr(clean_invisible_chars(test_str))) # 'HelloWorldTest'

提示：unicodedata.normalize('NFKC')是关键。它能把全角数字１２３转为半角123，把罗马数字Ⅻ转为12，还能处理带重音符号的字母（如é的两种Unicode表示法\u00e9和\u0065\u0301会统一为\u00e9）。这步不做，后续所有正则匹配都可能失效。

3.2 分词与边界识别：为什么“中文分词”不是Python内置功能？

Python的str.split()对英文有效，因为单词间有空格；但中文词与词之间没有天然分隔符。“我喜欢学习Python”要切分为["我", "喜欢", "学习", "Python"]还是["我喜欢", "学习", "Python"]？这取决于应用场景。搜索场景需细粒度（单字+词），摘要生成需粗粒度（语义完整词）。核心矛盾在于：字符串操作库（re、str）只认字节/字符边界，不认语义边界。解决方案分三层：

• 基础层（标点/空格分割）：用re.split(r'([^\w\u4e00-\u9fff]+)', text)按非字母数字非中文字符分割，保留分隔符便于后续还原
• 增强层（正则规则）：针对特定领域，如邮箱用r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b'，URL用r'https?://[^\s]+'
• 智能层（NLP模型）：用jieba（中文）、spaCy（多语言）进行语义分词。例如jieba.lcut("苹果发布了新iPhone")返回["苹果", "发布", "了", "新", "iPhone"]，比单纯按字切分更合理

实操心得：我们从不用单一方案。生产环境采用“分层过滤”策略：先用正则提取确定性实体（邮箱、手机号、日期），再用规则引擎处理业务关键词（如“订单号：OD123456”），最后对剩余文本用jieba分词。这样既保证关键信息100%召回，又避免NLP模型在噪声数据上误判。

3.3 编码一致性保障：构建跨平台安全的文本处理流水线

编码混乱的根源常是“混合信任”。比如读取一个CSV，我们信任文件头声明的编码，却忽略HTTP响应头的Content-Type: text/csv; charset=gbk；或信任数据库连接配置的charset=utf8mb4，却忘了MySQL客户端协议本身有独立编码设置。专业实践是：在流水线每个IO节点强制声明并验证编码。我们的检查清单：

1. HTTP请求：用requests.get(url).content获取原始字节，再用chardet.detect()探测，最后response.content.decode(detected_encoding)
2. 文件读取：优先用pathlib.Path.read_text(encoding='utf-8-sig')（自动处理BOM），失败则fallback到chardet
3. 数据库交互：在SQLAlchemy中显式设置create_engine('mysql+pymysql://...?charset=utf8mb4')，并在text()查询中指定collation='utf8mb4_unicode_ci'
4. 输出环节：写文件时强制encoding='utf-8'，并添加BOM（open(..., 'w', encoding='utf-8-sig')）确保Windows记事本兼容

注意：chardet不是银弹。它对短文本（<100字）准确率低于70%。我们的补救措施是：对探测置信度<0.8的文本，尝试utf-8、gbk、latin-1三种编码解码，用'ignore'错误处理，并对比解码后字符串的len()和repr()特征（如latin-1解码不会报错但会产生大量\xXX乱码），选择最合理的编码。

3.4 正则表达式工程化：从“能用”到“可靠”的质变

写一个能匹配邮箱的正则很容易，但写一个在生产环境稳定运行三年不误判的正则很难。关键在防御性设计：

• 锚定边界：用\b而非^/$，避免匹配到"abc@example.com.cn"中的"example.com"部分
• 避免灾难性回溯：r'(a+)+b'在匹配"aaaaaaaaaaaaa!时会指数级回溯。改用r'a+b'或r'(?>a+)b'（原子组）
• 预编译复用：pattern = re.compile(r'\d{4}-\d{2}-\d{2}')，避免在循环中重复编译
• 命名捕获组：r'(?P<year>\d{4})-(?P<month>\d{2})-(?P<day>\d{2})'，比group(1)语义清晰

实战案例：清洗电商SKU编码
需求：提取"iPhone15Pro-Max-256GB-银色-国行"中的型号、容量、颜色。
错误写法：r'(.+)-(.+)-(.+)-(.+)-(.+)'—— 无法处理"iPad-Air-64GB-深空灰"（只有4段）
正确写法：

import re SKU_PATTERN = re.compile( r''' (?P<model>[^-]+) # 型号：非-字符，贪婪匹配 (?:-(?P<variant>[^-]+))? # 变体（可选）：如Pro/Max -(?P<capacity>\d+[GT]B) # 容量：数字+GB/TB -(?P<color>[^-]+) # 颜色：非-字符 (?:-(?P<region>[^-]+))? # 地区（可选）：如国行/港版 ''', re.VERBOSE | re.IGNORECASE ) match = SKU_PATTERN.search("iPhone15Pro-Max-256GB-银色-国行") if match: print(match.groupdict()) # {'model': 'iPhone15Pro', 'variant': 'Max', 'capacity': '256GB', 'color': '银色', 'region': '国行'}

实操心得：正则越复杂，越要写单元测试。我们为每个业务正则维护一个test_cases.csv，包含10+正例和5+反例（如"iPhone15Pro-Max-256GB-银色-国行-赠品"应只匹配前5段），CI流程中自动运行，确保修改不破坏现有逻辑。

4. 实操过程与核心环节实现：一个电商评论情感分析前的完整清洗流水线

4.1 项目背景与数据痛点

我们为某跨境电商平台构建评论情感分析模型。原始数据来自三个渠道：

• App端评论：JSON API返回，含用户ID、评分、评论文本、时间戳
• 网页端评论：爬取HTML，含广告插入、用户头像HTML标签、回复嵌套
• 客服工单：Excel导出，含多列文本（问题描述、解决方案、客户反馈），列间有合并单元格

首期数据抽样10万条，经初步扫描发现：

• 32%的评论含HTML标签（如<br/>、<strong>）
• 18%的评论含emoji和特殊符号（如👍、❤️、[流泪]）
• 7%的评论含非UTF-8编码（主要是GBK的繁体中文）
• 23%的评论含营销话术模板（如“#好物推荐#”、“【限时优惠】”）

目标：输出纯净、统一编码、语义完整的纯文本，供BERT模型训练。

4.2 流水线设计：四阶段漏斗式清洗

我们摒弃“一步到位”的幻想，采用分阶段、可验证、可回滚的四阶段设计：

4.3 Stage 1 实现：编码统一与字节流校验

import chardet import codecs def detect_and_decode(byte_content): """智能探测并解码字节流""" # Step 1: 快速检测（采样前10KB） detect_result = chardet.detect(byte_content[:10000]) encoding = detect_result['encoding'] or 'utf-8' confidence = detect_result['confidence'] or 0.0 # Step 2: 尝试解码，失败则fallback for enc in [encoding, 'utf-8', 'gbk', 'latin-1']: try: if enc == 'latin-1': # latin-1永不失败，但需验证是否真为latin-1 decoded = byte_content.decode('latin-1') if not any(ord(c) > 255 for c in decoded): # 确保无超范围字符 return decoded, enc else: decoded = byte_content.decode(enc) # 验证解码后是否含大量字符（解码失败标志） if decoded.count('') / len(decoded) < 0.05: return decoded, enc except (UnicodeDecodeError, LookupError): continue raise ValueError(f"Cannot decode bytes with any known encoding") # 使用示例 with open('raw_comments.json', 'rb') as f: raw_bytes = f.read() text, used_encoding = detect_and_decode(raw_bytes) print(f"Used encoding: {used_encoding}, Confidence: {confidence:.2f}")

4.4 Stage 2 实现：HTML与JSON结构剥离

from lxml import html import json def extract_text_from_mixed_source(raw_input): """统一入口：处理JSON、HTML、纯文本""" if isinstance(raw_input, dict): # JSON对象：递归提取字符串值 def extract_strings(obj): if isinstance(obj, str): return [obj] elif isinstance(obj, dict): return sum((extract_strings(v) for v in obj.values()), []) elif isinstance(obj, list): return sum((extract_strings(v) for v in obj), []) else: return [] return " ".join(extract_strings(raw_input)) elif isinstance(raw_input, str): # 字符串：判断是否为HTML或JSON if raw_input.strip().startswith('<'): # HTML：用lxml安全提取文本 try: tree = html.fromstring(raw_input) # 移除script/style标签，提取可见文本 for elem in tree.xpath('//script | //style | //nav | //footer'): elem.drop_tree() return tree.text_content().strip() except Exception: return raw_input # 降级为原字符串 elif raw_input.strip().startswith('{') or raw_input.strip().startswith('['): # JSON字符串：解析后提取 try: data = json.loads(raw_input) return extract_text_from_mixed_source(data) except json.JSONDecodeError: return raw_input else: return raw_input # 纯文本 else: return str(raw_input) # 测试 html_sample = '<div><p>好评！<br/><strong>发货很快</strong></p><script>bad_code()</script></div>' print(extract_text_from_mixed_source(html_sample)) # "好评！ 发货很快"

4.5 Stage 3 实现：语义清洗与标准化

import re import unicodedata class TextCleaner: def __init__(self): # 预编译常用正则 self.emoji_pattern = re.compile( "[" "\U0001F600-\U0001F64F" # emoticons "\U0001F300-\U0001F5FF" # symbols & pictographs "\U0001F680-\U0001F6FF" # transport & map symbols "\U0001F1E0-\U0001F1FF" # flags (iOS) "\U00002702-\U000027B0" "\U000024C2-\U0001F251" "]+", flags=re.UNICODE) self.ad_template_pattern = re.compile( r'(?:#|\[|\【)(?:好物推荐|限时优惠|新品上市|官方认证)(?:#|\]|】)', re.IGNORECASE) self.whitespace_pattern = re.compile(r'\s+', re.UNICODE) def clean(self, text): if not isinstance(text, str): return "" # Step 1: Unicode标准化 text = unicodedata.normalize('NFKC', text) # Step 2: 移除emoji（保留文字描述） text = self.emoji_pattern.sub('', text) # Step 3: 移除广告模板 text = self.ad_template_pattern.sub('', text) # Step 4: 清理空白（保留段落） text = self.whitespace_pattern.sub(' ', text) text = re.sub(r'\n\s*\n', '\n\n', text) # 合并连续空行 # Step 5: 处理常见错别字（业务定制） replacements = { 'wifi': 'Wi-Fi', 'bluetooth': 'Bluetooth', 'iphon': 'iPhone', } for wrong, right in replacements.items(): text = re.sub(rf'\b{wrong}\b', right, text, flags=re.IGNORECASE) return text.strip() cleaner = TextCleaner() sample = "【限时优惠】iPhone15Pro👍发货很快！#好物推荐#" print(repr(cleaner.clean(sample))) # 'iPhone15Pro 发货很快！'

4.6 Stage 4 实现：业务词典增强与分词

import jieba # 加载电商领域词典（自定义） jieba.load_userdict('ecommerce_dict.txt') # ecommerce_dict.txt内容示例： # iPhone15Pro 100 n # Wi-Fi 100 nz # 256GB 100 m def enhance_segmentation(text): """增强分词：结合jieba与规则""" # Step 1: 先用jieba分词 words = jieba.lcut(text) # Step 2: 合并连续数字+单位（如"256GB"） merged_words = [] i = 0 while i < len(words): word = words[i] # 检查是否为数字+单位模式 if (i < len(words)-1 and re.match(r'^\d+$', word) and words[i+1].lower() in ['gb', 'tb', 'mb', 'kb']): merged_words.append(word + words[i+1]) i += 2 else: merged_words.append(word) i += 1 # Step 3: 过滤停用词（业务相关） stopwords = {'的', '了', '在', '是', '我', '有', '和', '就', '不', '人', '都', '一', '一个'} filtered_words = [w for w in merged_words if w not in stopwords and len(w) > 1] return filtered_words # 测试 text = "iPhone15Pro 256GB 很棒，Wi-Fi速度很快！" print(enhance_segmentation(text)) # ['iPhone15Pro', '256GB', '很棒', 'Wi-Fi', '速度', '很快']

4.7 流水线集成与监控

import logging from pathlib import Path class ETLPipeline: def __init__(self, log_level=logging.INFO): self.logger = logging.getLogger(__name__) self.logger.setLevel(log_level) def run(self, input_path, output_path): """执行完整流水线""" input_path = Path(input_path) output_path = Path(output_path) output_path.parent.mkdir(parents=True, exist_ok=True) stats = { 'total': 0, 'stage1_success': 0, 'stage2_success': 0, 'stage3_success': 0, 'stage4_success': 0, } with open(input_path, 'rb') as f_in, \ open(output_path, 'w', encoding='utf-8') as f_out: for line_num, line in enumerate(f_in, 1): stats['total'] += 1 try: # Stage 1 text, enc = detect_and_decode(line) stats['stage1_success'] += 1 # Stage 2 cleaned_text = extract_text_from_mixed_source(text) stats['stage2_success'] += 1 # Stage 3 cleaned_text = cleaner.clean(cleaned_text) stats['stage3_success'] += 1 # Stage 4 segmented = enhance_segmentation(cleaned_text) final_text = ' '.join(segmented) stats['stage4_success'] += 1 f_out.write(final_text + '\n') except Exception as e: self.logger.warning(f"Line {line_num} failed: {e}") # 记录失败样本供人工审核 with open(output_path.parent / 'failed_samples.log', 'a') as f_log: f_log.write(f"Line{line_num}: {line[:100]}... Error: {e}\n") # 输出统计报告 self.logger.info(f"Pipeline completed. Stats: {stats}") return stats # 启动流水线 pipeline = ETLPipeline() stats = pipeline.run('raw_comments.jsonl', 'cleaned_comments.txt')

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 “明明肉眼看着一样，为什么正则就是不匹配？”——Unicode等价性陷阱

现象：用正则r'cafe'匹配字符串"café"失败。
原因：é有两种Unicode表示：

• 预组合字符：\u00e9（单个码点）
• 分解序列：e+\u0301（组合重音符）
  浏览器显示相同，但字节序列不同。

排查技巧：

1. 用unicodedata.name(char)查看字符名称：

   import unicodedata s1 = "café" # \u00e9 s2 = "cafe\u0301" # e + combining acute print([unicodedata.name(c) for c in s1]) # ['LATIN SMALL LETTER C', ..., 'LATIN SMALL LETTER E WITH ACUTE'] print([unicodedata.name(c) for c in s2]) # ['LATIN SMALL LETTER C', ..., 'LATIN SMALL LETTER E', 'COMBINING ACUTE ACCENT']

2. 解决方案：统一用NFD（分解）或NFC（组合）标准化：

   s_normalized = unicodedata.normalize('NFC', s2) # 转为预组合形式 re.search(r'cafe', s_normalized) # 成功

5.2 “程序在本地跑得好好的，上线就报错”——系统默认编码差异

现象：开发机（macOS）上open('file.txt').read()正常，Linux服务器上抛UnicodeDecodeError。
根因：macOS终端默认UTF-8，Linux某些发行版（如CentOS 6）默认ANSI_X3.4-1968（即ASCII）。open()不指定encoding时，使用locale.getpreferredencoding()，结果不同。

排查技巧：

• 在服务器上运行locale命令，检查LANG变量
• 在Python中打印locale.getpreferredencoding()和sys.getdefaultencoding()
  终极方案：所有文件IO强制指定编码：

# 永远不要这样写 with open('file.txt') as f: # 依赖系统默认 content = f.read() # 必须这样写 with open('file.txt', 'r', encoding='utf-8') as f: # 显式声明 content = f.read()

5.3 “正则写了一天，还是漏掉几种情况”——业务规则爆炸式增长

现象：为匹配手机号，写了r'1[3-9]\d{9}'，上线后发现漏了170、171号段，又加r'17[0-1]\d{8}'，接着发现虚拟运营商16[257]……规则越来越长。

经验法则：

• 收集真实样本：从生产日志中提取1000个未匹配的“手机号”字符串，分析规律
• 用白名单代替黑名单：与其穷举所有号段，不如用运营商号段数据库（如phone-gen库）
• 引入置信度机制：对正则匹配结果，用长度、校验位（如Luhn算法）二次验证

def is_valid_phone(phone_str): # Step 1: 正则初筛 if not re.match(r'^1[3-9]\d{9}$', phone_str): return False # Step 2: Luhn校验（简化版） digits = [int(d) for d in phone_str] # 实际应用中，用标准Luhn算法或运营商API return sum(digits) % 10 == 0 # 示例逻辑

5.4 “清洗后文本变短了，但业务说丢数据了”——不可见字符的误删

现象：清洗后的评论长度平均减少15%，业务方反馈“客户强调的‘一定要快’被删成‘一定要’”。
真相：strip()删除了开头结尾的空白，但'一定要快\u200b'（末尾有ZWSP）被strip()误认为空白删掉了。

避坑指南：

• strip()只用于两端：text.strip()安全，但text.replace(' ', '')会误删有意义空格
• 区分空白类型：用string.whitespace（' \t\n\r\x0b\x0c'）而非盲目删\s
• 保留必要空白：段落间用\n\n分隔，行内用单空格，这是语义的一部分

5.5 “为什么同样的清洗脚本，处理100万行比10万行慢100倍？”——内存与算法复杂度误判

现象：脚本在小数据集上秒级完成，处理大数据时OOM（内存溢出）或卡死。
诊断步骤：

1. 用memory_profiler监控内存：@profile装饰函数，运行`python -m memory_profiler script