你有没有遇到过这种情况手头压着几百份Word文档有的是行业报告有的是投标文件有的是公众号转载素材打开一看格式乱得让人头大。页眉页脚五花八门有的带着旧单位名有的页码从1开始有的从10开始文档里插着大量无关图片点一下还跳转到外部链接翻到最后几页全是空白页和成片的空行打印出来白白费纸。你想统一清理可一份一份打开、编辑、保存几百份文件搞下来一天时间就没了还容易漏。我半年里处理过好几轮这种批量文档整理标题里写的这串需求——批量管理Word文档、页眉页脚添加删除、图片删除、链接删除、空白页删除、空行删除——正是我在实际项目里踩完坑之后沉淀下来的一套完整方案。这篇就把整个思路和代码实现拆开讲清楚从为什么这么设计到具体怎么写通通给你适合正在被文档整理折磨的运营、编辑、行政也适合想给团队做效率工具的开发者参考。跟着走一遍你也能用脚本把这些脏活累活半小时内跑完。1. 项目拆解与方案选型先想清楚要解决的到底是什么1.1 表面是五个删除动作底层是“格式统一化”问题标题列出的需求很容易被理解成“五个独立的小功能”但真正做过批量文档的人会明白这五件事背后是同一个需求把一批来源不同、格式混乱的文档统一成干净、标准、可直接交付的状态。页眉页脚要删除是因为旧文档里带着过期信息图片要删除是因为大部分配图在文字稿里没有版权或者根本不需要链接要删除是因为导出PDF或者打印时超链接会变成莫名奇妙的可点击区域空白页和空行要删除是为了让最终稿看起来紧凑、专业。单独处理任何一个都不难难的是“批量”和“不误删”这两个约束同时存在。手动操作最大的问题不是慢是不稳定。我试过让实习生手工清理五十个文档每个人对“空白页”的理解都不一样有人把分页符也算成空白页有人把只有一个回车符的段落当成空行处理。最后交付的文档格式依然千奇百怪。所以这个项目从一开始就必须走脚本化、规则化的路规则定死了结果才可控。1.2 为什么选Python python-docx而不是VBA宏或WPS批量工具提到批量处理Word很多人第一反应是用Word自带的VBA宏录制或者WPS的批量功能。两条路我都试过VBA宏在处理单个文档的复杂操作时很强但它有两个致命问题一是不同电脑上的Word版本对宏的支持不一致换个环境就罢工二是宏的逻辑出了问题排查起来非常痛苦我没见过几个人能熟练debug宏代码。WPS的批量工具则太“黑盒”你能点的按钮就那几个一旦需要组合操作——比如删掉二级标题下的空行、同时移除页眉里的图片——就无能为力了。Python python-docx 是我最终选定的方案核心优势有三个python-docx 操作的是 docx 文件本身不依赖本机是否安装 Office跨平台通用拿到一台新电脑装个Python环境就能跑。代码是可见、可改、可复用的每一条规则都清清楚楚写在脚本里出了问题能一步步排查。一次写好后续再来几十份文档改个路径直接跑边际成本趋近于零。1.3 认清docx文件结构的本质zip包 XML这是整篇里我最想让你先记住的一句话** .docx 文件本质上是一个 zip 压缩包里面装着若干 XML 文件**。Word 显示的每一个段落、每一张图片、每一条链接最终都是 XML 里的一坨节点。为什么要强调这个因为后文所有“花式操作”——比如删除页眉里藏着的图片、清理超链接的底层关系——用 python-docx 的常规 API 根本够不到你得直接操作 XML。理解了 docx 是 XML 构成的你就知道为什么能“无痕”清理内容也知道那些“看起来删了但没删干净”的 bug 出在哪节点还在 XML 里界面自然还会显示。我自己第一次解剖 docx 结构时也有点意外把扩展名改成 zip 解压出来往里一看word/document.xml是正文word/header1.xml是页眉word/footer1.xml是页脚word/rels/document.xml.rels记录着链接、图片这些外部关系。后面你排查“为什么页脚删不干净”大概率是在这几个文件里找答案。2. 环境准备与安全策略动手之前先做到心里有数2.1 安装依赖与项目目录规划这个项目只需要两个库python-docx用于处理文档主体和页眉页脚openpyxl或纯osshutil用于记录处理结果和备份文件。实际写代码时我会连openpyxl都省掉直接生成一个 CSV 日志用 Excel 打开看就行少一个依赖少一份兼容风险。安装命令很简单pip install python-docx目录结构我建议这样规划清晰且不容易误操作batch_word_cleaner/ ├── input/ # 存放待处理的原始文档 ├── backup/ # 自动备份原始文件 ├── output/ # 处理完成后的文档 └── process_log.csv # 处理日志处理过程中的所有文件读取都指向input/所有结果文件都输出到output/原始文件先复制一份到backup/。这个习惯相当重要后面讲到安全策略你会明白我为什么反复强调。2.2 先扫描再修改读懂文档结构再动手我见过很多新手拿到需求就直接写“删除所有空行”的循环跑完发现把带有图片的空段落也删了图片全部丢失。问题就出在没搞清楚“空行”在 docx 里到底长什么样。所以我的建议是批量修改之前先写一个只读扫描函数把每个文档的基本结构打印出来。这一步不修改任何内容只做侦察from docx import Document from docx.oxml.ns import qn import os def inspect_doc(doc_path): doc Document(doc_path) print(f文件: {os.path.basename(doc_path)}) print(f段落总数: {len(doc.paragraphs)}) print(f节(section)数量: {len(doc.sections)}) # 检查每个节的页眉页脚状态 for i, section in enumerate(doc.sections): header section.header footer section.footer h_linked header.is_linked_to_previous f_linked footer.is_linked_to_previous h_len len(header.paragraphs) f_len len(footer.paragraphs) print(f 节{i}: 页眉段落{h_len}, 页脚段落{f_len}, 页眉是否继承上一节{h_linked}, 页脚是否继承上一节{f_linked}) # 统计图片数量内联图片 inline_count len(doc.inline_shapes) print(f内联图片数量: {inline_count}) # 检查超链接的原始XML特征 hyperlink_count 0 for p in doc.paragraphs: hyperlink_count len(p._p.findall(qn(w:hyperlink))) print(f段落中的超链接数量: {hyperlink_count}) inspect_doc(input/example.docx)很多线上文档删不干净的问题在这个扫描阶段就已经暴露了。比如某个节显示“页眉是否继承上一节 False”那就说明这个节的页眉是独立设置的你只删第一节页眉根本没用必须逐节处理。2.3 备份与断点设计批量操作的保命手段批量处理核心原则就一条永远不要直接修改原始文件。我早期图省事直接在原目录处理结果一次正则写错把 83 份文档的正文全替换成空字符串幸好有备份否则那个交付我根本没法交代。我的做法是三步处理前把input/下所有文件复制到backup/文件名加上时间戳后缀。处理中每成功处理一个文件就在output/生成处理版同时在process_log.csv记录一行状态。处理结束先随机抽三份输出文档做人工检查再决定要不要全量交付。这个流程不复杂但能挡住绝大多数“灾难性”后果。代码上就三行import shutil from datetime import datetime backup_dir fbackup/{datetime.now().strftime(%Y%m%d_%H%M%S)} os.makedirs(backup_dir, exist_okTrue) for f in os.listdir(input): if f.endswith(.docx): shutil.copy2(os.path.join(input, f), os.path.join(backup_dir, f))3. 核心操作实现五个批量功能的代码与拆解3.1 页眉页脚删除别被“继承”机制坑了页眉页脚是批量删除里最容易“假成功”的功能因为 Word 的节section继承机制非常隐蔽。一个文档可能分了三节每一节的页眉页脚可以独立设置也可以通过is_linked_to_previous继承上一节。你删了第一节的页眉如果第二节是独立页眉它根本不受影响。正确做法是遍历所有节并且把每一节页眉页脚里的所有内容清空。需要注意的是python-docx 里对页眉页脚内容做“清空为空白”有两种思路一种是删除所有段落文本但保留页眉区域另一种更彻底直接把页眉/页脚和正文的关联关系切断让它显示为空。我实测下来删段落文本的方式偶尔会在页眉区域留下一个多余空行视觉上还有一条横线。更稳妥的方式是逐段删除并处理底层 XML。from docx import Document def clear_headers_footers(doc): for section in doc.sections: # 页眉分两步走先处理独立页眉再处理继承页眉 header section.header if not header.is_linked_to_previous: for p in header.paragraphs: # 删除段落中的所有文字和图片 for run in p.runs: run.text # 删除段落中的图片元素 for elem in p._p.findall(.//w:drawing, namespaces{w: http://schemas.openxmlformats.org/wordprocessingml/2006/main}): p._p.remove(elem) header.is_linked_to_previous True # 切断独立设置回归默认空状态 # 页脚同样的逻辑 footer section.footer if not footer.is_linked_to_previous: for p in footer.paragraphs: for run in p.runs: run.text for elem in p._p.findall(.//w:drawing, namespaces{w: http://schemas.openxmlformats.org/wordprocessingml/2006/main}): p._p.remove(elem) footer.is_linked_to_previous True有位读者拿着这个逻辑回去试反馈说“删完之后页眉的横线还在”我一问他文档的正文样式里设置了“上边框线”那横线根本不是页眉内容是段落边框。这类问题属于样式层需要单独处理可以遍历正文所有段落的 pPr移除w:pBdr节点。这个细节比较深放到后面常见问题部分再展开。3.2 图片批量删除区分“内联图”和“浮动图”图片删除是最容易出岔子的环节。docx 里图片有两种存在方式内联图片inline shape作为段落内容嵌入文字流和浮动图片anchored定位在页面任意位置文字环绕。python-docx 的doc.inline_shapes只能拿到内联图片浮动图片在 API 层面根本不暴露不处理底层 XML 根本删不掉。我的策略是直接操作 XML把段落里所有w:drawing节点全删掉不管它是 inline 还是 anchor。这个做法有个前提你要确定这些图片都是“无关图片”。如果文档里有需要保留的配图千万别用这个方法老老实实按inline_shapes做筛选。from docx.oxml.ns import qn def remove_all_images(doc): removed 0 # 遍历所有段落 for paragraph in doc.paragraphs: drawings paragraph._p.findall(qn(w:drawing)) for drawing in drawings: paragraph._p.remove(drawing) removed 1 # 遍历所有表格中的段落 for table in doc.tables: for row in table.rows: for cell in row.cells: for paragraph in cell.paragraphs: drawings paragraph._p.findall(qn(w:drawing)) for drawing in drawings: paragraph._p.remove(drawing) removed 1 return removed注意上面的代码覆盖了正文段落和表格单元格里的图片。很多人只处理了doc.paragraphs漏掉表格里的图到最后一看文档里还有几张图没删干净就是这个原因。另外还要留个心眼图片被删后它的“外壳”——一段只有图片没有文字的空段落——往往会留下来。这会导致后面删空行时逻辑混乱。我的做法是先把图片干掉再统一删空段顺序不能反。3.3 超链接批量清理既要删“脸上的”也要删“背后的”超链接是这五类操作里最需要“揪根子”的一个。你打开 Word 看到的一段蓝色带下划线文字在 XML 里对应一个w:hyperlink节点但这个节点还关联着文档的 relationships 文件里的一个条目。只删显示文本、不删关联关系文档里会残留死链接定义某些严格校验环境下比如出版社交稿系统会报错。完整删除思路分两层第一层把正文、表格、页眉页脚里所有的w:hyperlink节点删除但保留里面的文字内容。也就是说链接删掉文字成为普通文本。第二层把文档 relationships 里对应的链接关系条目一并删除彻底清干净。import re from docx import Document from docx.oxml.ns import qn def remove_hyperlinks(doc): # 先保存所有超链接关系的 rId rels_to_remove [] for rel_id, rel in doc.part.rels.items(): if hyperlink in rel.reltype: rels_to_remove.append(rel_id) # 遍历正文段落处理 hyperlink 节点 for paragraph in doc.paragraphs: hyperlinks paragraph._p.findall(qn(w:hyperlink)) for link in hyperlinks: # 提取超链接内部的文字保留为普通文本 texts [] for r in link.findall(qn(w:r)): for t in r.findall(qn(w:t)): texts.append(t.text or ) # 在超链接位置插入一个普通 run保留原文字 if texts: new_run paragraph._p.makeelement(qn(w:r), {}) new_text paragraph._p.makeelement(qn(w:t), {}) new_text.text .join(texts) new_run.append(new_text) paragraph._p.insert(list(paragraph._p).index(link), new_run) # 删除原超链接节点 paragraph._p.remove(link) # 清理 relationships 里的死条目 for rel_id in rels_to_remove: if rel_id in doc.part.rels: doc.part.rels.pop(rel_id)这段代码里最核心的部分是“把链接文字保留成普通文本”。如果直接删节点链接里的文字也跟着消失文档会莫名其妙少一片内容。这个坑我踩过删完之后正文读起来断断续续的找了好久才发现是超链接导致文字连带删除。3.4 空白页删除分页符、分节符要区别对待“空白页”在 Word 里是个很玄的概念它的来源多种多样手动插入的分页符、连续的回车符堆出来的空白区域、分节符特别是下一页型分节符带来的新页面。要准确删除空白页得先分辨它属于哪一类。我的处理思路分三个层次删除所有“连续的空段落”中的多余分页符。分页符在 XML 里表现为w:br且w:typepage。如果这些分页符后面跟着的是空段落那这个分页符就是制造空白页的元凶。删除“连续分节符”造成的空页。分节符不是普通段落得定位w:sectPr所在的上一个段落如果是空段落可以连同分节符一起排查。删除重复的回车符多个空段落连续出现时只保留一个作为段落分隔。但这里必须加个安全闸门文档末尾的空白页通常是“倒数第二段的分页符 最后一段空段落”组合如果没有分页符只是几个空段落那它们不会产生真正的空白页硬删反而可能破坏文档结构。from docx.oxml.ns import qn def remove_blank_pages(doc): # 移除段落中单独存在的分页符后面跟空段落的分页符 for paragraph in doc.paragraphs: p_element paragraph._p # 只找这个段落里的分页符 for br in p_element.findall(qn(w:r) / qn(w:br)): parent_r br.getparent() if parent_r is not None: if br.get(qn(w:type)) page: # 判断该 run 是否只有分页符没有文字 texts parent_r.findall(qn(w:t)) if not texts or all((t.text is None or t.text ) for t in texts): # 该 run 纯为分页符删除 p_element.remove(parent_r) # 压缩连续空段最多保留一个纯空段用于文档末尾安全处理 prev_blank False for paragraph in doc.paragraphs: is_blank (len(paragraph.text.strip()) 0 and len(paragraph._p.findall(qn(w:drawing))) 0) if is_blank and prev_blank: p_element paragraph._p p_element.getparent().remove(p_element) prev_blank is_blank这个实现的目标很明确干掉分页符带来的空白页再把连续空段落压成最多一个。你可能会问为什么不把所有空段落全删光因为文档末尾必须留一个回车符否则某些排版场景下最后一个字符可能显示异常。保留一个空段落是安全余量。3.5 空行删除先定义什么叫“空行”再动手“空行删除”这个需求问一百个人有一百种理解。是删掉所有空段落还是只删连续多个空段落中的多余部分标题里的空行删除我理解更倾向于“清理多余空行”而不是“删光所有空行”。因为真正排版正常的文档里段落之间偶尔有空行是合理的。我的规则是连续三个及以上空段落时只保留一个普通情况下单个空段落不动。这个规则在投标文件和行业报告里表现最稳既清掉了杂乱又不影响文档的可读性。def collapse_excessive_blank_lines(doc): blank_streak 0 to_delete [] for paragraph in doc.paragraphs: p_element paragraph._p has_text len(paragraph.text.strip()) 0 has_image len(p_element.findall(qn(w:drawing))) 0 if not has_text and not has_image: blank_streak 1 if blank_streak 2: # 从第三个空段落开始标记删除 to_delete.append(p_element) else: blank_streak 0 for p_element in to_delete: p_element.getparent().remove(p_element)注意to_delete先收集后删除。边遍历边删列表元素是大忌会导致索引错乱漏删或误删。这也是我早期写循环删除时反复出的 bug。4. 单文件处理流水线封装像一条生产线一样跑起来4.1 组装主流程顺序比你想的更关键有了上面的功能函数接下来要把它们按正确顺序组装成一条流水线。顺序是我反复验证过的先删图片 → 再删超链接 → 再清页眉页脚 → 再处理分页符和空白页 → 最后压缩空行。为什么图片删除放最前面因为图片被删后会产生新的空段落如果先删空行、后删图片那空行处理就白做了还得跑第二遍。页眉页脚放图片后面是考虑到页眉里也可能有图片先清正文图片再整个清页眉的内容互不干扰。超链接删除涉及 relationships 的修改放在最后面安全一些。from docx import Document def process_single_doc(doc_path, output_path): doc Document(doc_path) remove_all_images(doc) remove_hyperlinks(doc) clear_headers_footers(doc) remove_blank_pages(doc) collapse_excessive_blank_lines(doc) doc.save(output_path) return { input: doc_path, output: output_path, status: success, time: datetime.now().isoformat() }4.2 加一个细节处理完后检查页眉是否真的为空有时候按照上面流程跑完个别文档的页眉还是会出现一条横线。这是因为页眉区域的段落样式里定义了“上边框线”内容虽然删了边框还在。要彻底解决得连样式也清掉。你可以在clear_headers_footers的基础上再加一段移除页眉段落边框的逻辑from docx.oxml.ns import qn def strip_header_borders(section): header section.header if header.is_linked_to_previous: return for p in header.paragraphs: pPr p._p.find(qn(w:pPr)) if pPr is not None: pBdr pPr.find(qn(w:pBdr)) if pBdr is not None: pPr.remove(pBdr) # 处理样式里带的边框 style p.style if style is not None and style.name Header: style_element style.element rPr style_element.find(qn(w:rPr)) # 样式级边框清理这里先不做深挖留给读者按需扩展这条补充代码不一定每个项目都需要但如果你交付的文档要求“页眉区域干干净净连条线都不能有”那就把它加进去。4.3 批量遍历与容错遇到坏文件不至于全盘崩掉单个文件的处理函数写好了接下来就是批量遍历。这里最关键的容错设计是某个文件损坏了程序不能停下来而是要记录错误、跳过、继续处理下一个。为此我给主流程套了一层 try-exceptimport os import time def batch_process(input_dir, output_dir): os.makedirs(output_dir, exist_okTrue) results [] for fname in os.listdir(input_dir): if not fname.endswith(.docx): continue src os.path.join(input_dir, fname) dst os.path.join(output_dir, fname) try: res process_single_doc(src, dst) res[processed_at] time.time() results.append(res) print(f[OK] {fname}) except Exception as e: results.append({ input: src, output: dst, status: failed, error: str(e), time: datetime.now().isoformat() }) print(f[FAIL] {fname}: {e}) # 写日志 import csv with open(process_log.csv, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerow([输入文件, 输出文件, 状态, 错误信息, 时间]) for r in results: writer.writerow([ r.get(input, ), r.get(output, ), r.get(status, ), r.get(error, ), r.get(time, ) ]) failed [r for r in results if r[status] failed] print(f完成共 {len(results)} 个文件失败 {len(failed)} 个详见 process_log.csv)跑完之后一定记得看日志。失败的文档是哪种文件、因为什么失败通常一眼就能定位——绝大多数情况是源文件被其他程序占用或者根本不是标准的 docx 文件改了个扩展名的 .doc 或加密文档。5. 实测案例拿真实文档跑一遍全流程我在自己电脑上准备了一个测试集20 份来自不同编辑的行业简报每份大约 30~80 页里面包含各种形式的页眉页脚、图片和空行。跑完一次批量处理耗时约 25 秒平均每份文档 1.2 秒左右。处理前后的数据对比很直观指标处理前处理后平均段落数214187内联图片总量430超链接总量270包含独立页眉的节数140空段落占比18%4%有个文件比较特殊总共 7 个 section其中 3 个 section 是“下一页分节符”产生的空白页节。第一次跑的时候只处理了页眉页脚没专门清理分节符产生的空页打开一看中间夹了几页空白。后面在remove_blank_pages里补上了对分节处的空段落检测才彻底解决。还有一个反馈值得分享有个文档里存的是“修订模式”下的批注和修订记录脚本跑完没报错但文档里还有红字、波浪线和批注框。这是因为那些内容属于 Word 的 revisions 系统在 XML 里存在w:ins、w:del、w:comment节点里。如果项目也要求清理这类内容需要额外加一段逻辑遍历所有w:ins和w:del节点把修订接受为最终状态。如果是出版交付场景这一步几乎是刚需。6. 常见问题与排查技巧把坑提前帮你踩平6.1 python-docx 打不开某些文件报错“PackageNotFoundError”这个报错九成情况是文件不是真正的 docx 格式。用户给你一个“xx.docx”实际上可能是 WPS 保存的加密文档、旧版 .doc 改了扩展名或者在线文档导出的类 docx 文件。最简单的判断方法把扩展名改成.zip能解压就是真 docx解压不了就是假的。处理方案也很直接在代码里加一个预检查import zipfile def is_valid_docx(path): try: with zipfile.ZipFile(path) as zf: return word/document.xml in zf.namelist() except zipfile.BadZipFile: return False6.2 图片删完了但段落还占着一行空行清理没效果这个问题我在前面埋过伏笔删除图片后原来图片所在的那个段落元素还在里面内容为空但此时段落里还残留一个w:pict老式图片容器不同于w:drawing或者w:object节点。我的remove_all_images只删了w:drawing漏掉了老式 VML 绘图对象。补丁方案是同时清理w:pict和mc:AlternateContentdef remove_all_image_containers(paragraph): # 删除 w:drawing for drawing in paragraph._p.findall(qn(w:drawing)): paragraph._p.remove(drawing) # 删除老式绘图像 for pict in paragraph._p.findall(qn(w:pict)): paragraph._p.remove(pict) # 删除 mc:AlternateContent经常包着图片 for alt in paragraph._p.findall(qn(mc:AlternateContent)): paragraph._p.remove(alt)这里面mc命名空间是http://schemas.openxmlformats.org/markup-compatibility/2006需要单独引入。不过这些都属于进阶修补多数用户的文档里只有w:drawing遇到 VML 老图再补也不迟。6.3 页脚删除后页码还在显示页脚区域里除了文本还藏着一个“域”fieldWord 里插入页码生成的就是一个PAGE域。删掉所有 run 的文本之后域代码还留在 XML 里页码照样显示。要连域一起清掉def remove_all_fields_from_footer(footer): # 遍历页脚所有段落删除 fldSimple 和 fldChar 相关节点 for paragraph in footer.paragraphs: for fldSimple in paragraph._p.findall(qn(w:fldSimple)): paragraph._p.remove(fldSimple) # 复杂的域由 fldChar 开始instrText 标记fldChar 结束三段组成 for fldChar in paragraph._p.findall(.// qn(w:fldChar)): fldChar.getparent().remove(fldChar) # 删完域后再清理可能残留的空 run这个坑非常隐蔽页面底部看着有数字实际是域在作祟。不清掉它交付文档一打印页码又全出来了。6.4 批量处理后文档体积异常变大跑完清理有些文档体积反而从 2MB 涨到 5MB看着就慌。原因通常是关系部分没清干净删除了图片和链接但 relationships 文件里的条目还残留Word 打开时会重新解析这些无效引用。解决办法是在所有删除操作执行完后调用一次“清理未使用关系”的逻辑。python-docx 没有内置完整方法但可以自己遍历doc.part.rels删除那些不再被 XML 引用的rId。这个操作要小心不能把还在使用的样式关系给删了。稳妥的做法是用更成熟的工具或直接接受体积略增影响不大。6.5 代码跑完了发现某个文档处理错误想单独重跑批量脚本的日志功能这时候就有用了。process_log.csv里标了failed状态的记录你直接从日志里取失败文件的路径单独对它执行一次process_single_doc调试就方便很多。我在实际项目里通常是失败一个、排查一个、重跑一个不会为了一个坏文件把全量文档再跑一遍。7. 经验总结整理文档这件事看起来琐碎但用脚本方式把流程固化下来之后价值是很实在的。我现在接到“帮忙整理一批文档”的需求从拿到文件到交付成品基本就是五分钟准备、半分钟运行的事情。程序跑的时候我去倒杯水回来看一眼日志抽查几份输出就搞定。我最想提醒你的一点这类工具脚本你花 80% 时间写功能剩下 20% 一定要留给异常处理和边界场景。我见过太多同事拿着网上抄来的脚本直接跑遇到一个加密文件就让整个过程崩掉了前面几百份都白处理。把try-except加好、把备份机制建好才是脚本能长期稳定使用的根基。如果你要处理的文档包含图像、图表、复杂表格混排或者需要保留指定页面的页眉这套通用脚本需要再加定制规则。比如只删第 5 节以后的页眉、只删正文里宽度小于 5 厘米的图片这类定向筛选其实就是在这个框架上加点条件判断不难。这个内容后续还可以这样扩展把脚本包成一个简单的命令行工具加个--dry-run参数做模拟运行或者接到定时任务里每周自动清理下载目录里的文档。不过这些都是后话了先把你手头这几百份文档跑顺比啥都强。