应遍历所有段落和表格单元格中的run对象逐个替换，用run.clear()和run.add_text()保留格式，页眉页脚需显式访问section.header/footer，文本框等特殊区域无稳定api支持。
用 python-docx 替换正文中的文字
python-docx 不能直接全局替换，必须遍历所有段落和表格单元格里的 run 对象。它不支持正则、不处理页眉页脚、也不进文本框——这些地方的文字会被完全忽略。
常见错误是只遍历 document.paragraphs，漏掉表格内容。实际文档里大量文字藏在表格中，比如报价单、参数表。
- 逐个检查
paragraph.runs，对每个run.text做字符串替换（注意：替换后要重置run.text） - 再遍历所有
table→row→cell→paragraphs→runs - 避免在遍历时修改
runs列表长度（比如边遍历边删 run），否则会跳过后续项；应先收集需替换的run，再统一赋值
保留原格式的替换怎么做
直接改 run.text 会丢失加粗、颜色、字体等格式，因为新文本没有继承原 run 的属性。真正“保留格式”的替换，本质是清空旧文本、插入新文本，同时复用原 run 的所有样式。
实操上更稳妥的做法是：用 run.clear() 清空内容，再调用 run.add_text(new_text)。这样字体、字号、颜色、下划线等全部保留。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 不要用
run.text = new_text，这会切断格式继承链 - 如果新文本含换行符
\n，add_text()不会自动换行，需拆成多个run或用paragraph.add_run()配合add_break() - 中文标点或全角空格替换后可能显示异常，检查源文档是否用了特殊字体，替换后建议手动验证渲染效果
页眉、页脚、文本框里的文字怎么换
python-docx 默认不暴露页眉页脚和文本框（Shape）里的文字，它们属于不同的对象层级。这部分必须显式访问，且结构嵌套更深。
页眉页脚要从 section.header / section.footer 入口开始，文本框则要遍历 document.part._element.xpath('//wp:anchor')（需 lxml 支持），操作成本高、稳定性差。
- 页眉页脚替换：遍历
document.sections，对每个section.header.paragraphs和section.footer.paragraphs执行同正文的run替换逻辑 - 文本框基本无稳定 API 支持，python-docx 0.8.11 及之前版本无法可靠读取其内容；如必须处理，建议先导出为 PDF + OCR，或改用 win32com（仅 Windows）
- 公式、批注、超链接锚文本也不在默认遍历范围内，需单独处理
paragraph._element.xpath
为什么 re.sub 替换后格式错乱或丢失
直接对整个段落 paragraph.text 提取后再用 re.sub 替换，再塞回去，看似简洁，实则破坏了 run 的分段逻辑。Word 把同一段落里不同格式的文字拆成多个 run，比如“价格：**￥120**元”可能是三个 run（普通、“￥120”加粗、“元”普通）。整段取 text 再设回去，就合并成了一个 run，格式全丢。
- 正则替换必须在
run级别做，不能跨 run 合并处理 - 若需正则能力，对每个
run.text单独调用re.sub(pattern, repl, run.text)，再用run.clear()+run.add_text()写回 - 注意
re.sub的repl不能含格式控制字符，否则写入后可能触发 Word 异常解析（如意外插入 tab 或软回车）
批量替换真正麻烦的不是逻辑，而是 Word 文档本身结构的碎片化——同一个语义块（比如一个标题）可能被拆进多个 run、甚至跨段落或进文本框。动手前先用 print([r.text for r in p.runs]) 看几段真实数据，比硬写通用代码更省时间。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
