做了好几年办公自动化方向的事情我发现一个规律真正让运营、行政、开发头疼的不是不会写文档而是要反复处理一堆“格式差不多但细节全不一样”的Word文件。这套东西如果纯手工做一次两次还能忍几十上百份的时候人一定会疯。把Python拉进来以后事情就变成了一条流水线数据丢进去文档批量出来字体统一、表格整齐、页码自动生成整个人从重复劳动里解放出来。这篇文章就把这套“Python操作Word自动化排版”的完整流程拆开讲清楚从环境准备到模板渲染从段落到表格从页码到目录再附上我实际踩过的坑和排查方法争取你看完就能用。有人可能会问Word排版用VBA不是更直接吗确实可以但VBA的局限在于它绑定Office环境只能在Windows上跑而且被人为限制宏的时候连执行都困难。Python的优势是跨平台、可嵌入现有业务系统、能直接处理数据源配合python-docx这类库不需要安装Office就能读取和生成docx文件。所以这篇文章主要围绕python-docx来讲只有涉及公式域、原生Word行为这类复杂需求时我才会引入pywin32作为补充。1. 项目思路拆解Word自动化排版的本质是“数据 模板”1.1 先搞清楚排版里的重复劳动到底有哪些我做过的Word自动化需求绝大多数可以归成三类。第一类是批量填充比如合同、报价单、通知主体格式早就定好变化的是客户名、金额、日期、产品清单这些数据。第二类是格式统一从不同渠道收集来的文本、表格字体五花八门段落缩进乱七八糟需要一把梭变成一个风格。第三类是结构化生成比如根据数据库记录一次性生成几百份报告每个报告包含表格、图表、附加说明纯手工得做到地老天荒。这些工作的共同点就是“规则明确、重复度高”。只要规则明确就能转成代码逻辑只要重复度高就值得写自动化脚本。一次写脚本可能要花半天但它能帮你省下后面无数个周末。这个账怎么算都划算。1.2 为什么选择python-docx而不是纯VBA或pywin32先说结论处理.docx格式的常规排版python-docx是第一选择。它不依赖Office程序内部直接操作XML结构速度快跨平台可用在Linux服务器上也能跑。你写完脚本设个定时任务数据到位后自动出文档体验甚至比人工打开Word还顺畅。python-docx处理不了的特殊场景再用pywin32。pywin32的本质是Windows下的COM调用相当于在Python里操作Word应用本身能做几乎一切人手动能做的操作包括插入公式、执行宏、调用内置对话框。代价是必须有Windows加Word环境进程管理不当还容易造成“Word关闭慢/卡顿”的情况。多数项目里python-docx负责80%的排版工作pywin32只在收尾阶段处理少数复杂对象。1.3 整体流程应该怎么设计一套成熟的Word自动化排版流程我习惯拆成四步。第一步是数据准备把需要填入文档的内容从Excel、数据库、API接口里抽出来清洗成规整的Python数据结构第二步是模板构建用python-docx创建骨架文档包括页面设置、全局样式、页眉页脚、表格框架第三步是数据填充与格式调整把数据写进段落到run的粒度同时确保字体、缩进、间距符合规范第四步是输出校验生成一个中间文件解压看XML或者直接转PDF预览确认无误后统一命名输出。这四步里最容易翻车的是第三步。Word里文字的格式是分两层控制的文档级样式是一层run级直接格式是另一层而且run级格式的优先级更高。很多人写成“给paragraph设一下字体就完事”结果文档打开后发现只有部分文字变了其余全跟着默认样式走就是没有理解run级格式的原理。2. 环境准备与基础概念装好库、认识docx结构2.1 安装python-docx并解决常见环境坑安装很简单一条命令就能搞定pip install python-docx如果你环境里有多个Python版本或者公司电脑有权限限制我建议用虚拟环境python -m venv word_env word_env\Scripts\activate pip install python-docx使用虚拟环境的好处是隔离依赖避免把系统Python搞得一团糟。还有两个新手特别容易踩的坑。第一import时写的是import docx不是import python_docx库名和导入名不一致。第二python-docx只能处理现代格式的.docx不能直接处理旧格式的.doc。遇到.doc文件先想办法转成.docx用WPS或者Office打开另存一下就行也可以用LibreOffice做批量转换。2.2 认识docx的本质一个带特定结构的zip压缩包这一步非常重要理解了它你就掌握了调试Word自动化的主动权。一个.docx文件本质上是zip压缩包里面有一堆XML文件真正的内容主体在word/document.xml里样式在word/styles.xml里页眉页脚分别在word/header1.xml和word/footer1.xml里。所以当排版结果不符合预期时最快的排查方法就是把这个docx的后缀名改成zip解压打开对应的XML看看节点上到底写入了什么属性。格式问题在XML面前无处遁形。python-docx所有的API操作底层都不过是往这些XML里增加属性节点罢了懂了这个原理很多怪异现象都能想通。2.3 python-docx的核心对象模型python-docx的对象模型和Word文档的结构是对应的Document代表整个文档Section代表页面设置的片段一个文档可以有多个分节Paragraph代表段落Run代表段落里具有相同格式的连续文本片段Table代表表格由行Row和单元格Cell组成。排版时最容易忽略的就是Paragraph和Run的区别。字体、字号、加粗、颜色这些字符级格式都作用在Run上不是作用在Paragraph上。段落级格式比如对齐、缩进、行距、段前段后作用在ParagraphFormat上。写代码的时候一旦混了就会出现“设置了半天没反应”的尴尬局面。3. 核心排版实操页面、字体、段落、表格、页码、目录3.1 页面设置A4纸、页边距和分节页面设置是整个文档排版的地基。python-docx里通过Section对象控制页边距和纸张大小from docx import Document from docx.shared import Pt, Cm doc Document() sec doc.sections[0] sec.page_width Cm(21.0) sec.page_height Cm(29.7) sec.top_margin Cm(2.54) sec.bottom_margin Cm(2.54) sec.left_margin Cm(3.17) sec.right_margin Cm(3.17)上面这段就是标准A4纵向页面、上下边距2.54厘米、左右边距3.17厘米对应Word里最常见的“普通”页边距预设。如果你做的是横向表格页可以另起一个分节单独设置横向尺寸内容也不会互相影响。分节的本质是文档里Section的增删python-docx通过add_section()新增分节然后分别设置各自的页面参数。3.2 字体设置为什么中文字体经常设置无效中文字体不生效是Word自动化排版的第一个大坑。很多人会这样写run paragraph.add_run(你好世界) run.font.name 宋体生成文件后打开一看字体没变。原因在于Word的字体属性分西文字体和中文字体两套run.font.name只能设置西文字体中文字体需要往run的rPr里设置w:eastAsia属性必须借助底层XML操作from docx.oxml.ns import qn def set_chinese_font(run, font_name宋体, sizePt(12), boldFalse, colorNone): run.font.name Times New Roman r run._element rPr r.get_or_add_rPr() rFonts rPr.find(qn(w:rFonts)) if rFonts is None: rFonts rPr.makeelement(qn(w:rFonts), {}) rPr.append(rFonts) rFonts.set(qn(w:eastAsia), font_name) run.font.size size run.font.bold bold这段代码的意思是西文字体统一用Times New Roman中文部分指定为宋体这样写出来的文档才符合中文公文惯例。我一般会把这个函数单独放到一个工具模块里所有文字写入都走它避免零散重复代码。字体这块还有一个容易被忽略的问题如果你的电脑没装目标字体Word会启动字体替换机制。比如指定了“黑体”但系统没有Word会用默认字体渲染屏幕上看不出问题打印或导出PDF时却可能错位。所以我建议字体名称尽量使用系统自带或你确定目标机器上存在的字体尤其在企业内部批量生成文档时最好先确认终端用户的电脑装了哪些字体。3.3 段落排版首行缩进、行距、对齐和间距段落格式是中文排版的脸面。正文需要首行缩进两个字符标题要居中段前段后要有合适的间距行距要确保可读性。python-docx里的实现方式如下paragraph doc.add_paragraph() paragraph.alignment WD_ALIGN_PARAGRAPH.JUSTIFY paragraph_format paragraph.paragraph_format paragraph_format.first_line_indent Pt(24) # 12pt字号下2字符约等于24pt paragraph_format.line_spacing 1.5 paragraph_format.space_before Pt(6) paragraph_format.space_after Pt(6)大部分情况下用Pt作为缩进单位够用了。但严格按Word语义首行缩进“2字符”应该使用w:firstLineChars200这个XML属性而不是单纯用长度单位。因为长度单位会跟随字号变化而“字符”单位不会。如果你希望文档在不同字号下都能保持精确的“缩进两字符”可以用底层XML手动设置ind paragraph_format.element.get_or_add_ind() ind.set(qn(w:firstLineChars), 200)两种方式各有适用场景。公文类文档对缩进要求严格我倾向于字符单位一般业务文档用Pt简单够用也方便控制实际视觉距离。段落对齐方式中正文我常用两端对齐JUSTIFY标题用居中CENTER表格里的数字通常用居中或右对齐。不要每个段落都硬编码建议把标题、正文、表格文本的样式分别封装成函数统一管理。3.4 表格排版列宽、表头、合并单元格和常见坑表格是Word排版的重灾区也是最容易出现“列宽无法拖动”这类问题的场景。python-docx创建表格本身很简单table doc.add_table(rows3, cols4) table.style Table Grid这样表格已经有了边框每列宽度是Word默认等分。然而实际需求往往是某些列宽一点、某些列窄一点。很多人直接设置cell.width发现不生效或者生成后在Word里拖不动列宽这是因为Word默认开启了“自动调整列宽”属性表格会根据内容重新计算宽度。解决列宽问题的关键是两件事。第一把表格布局设置为固定fixed。第二对每一行的每个单元格都显式设置宽度而不是只设置表头。from docx.oxml import OxmlElement from docx.oxml.ns import qn tblPr table._tbl.tblPr layout OxmlElement(w:tblLayout) layout.set(qn(w:type), fixed) tblPr.append(layout) col_widths [Cm(2.5), Cm(4.0), Cm(3.0), Cm(3.5)] for row in table.rows: for idx, cell in enumerate(row.cells): cell.width col_widths[idx]固定布局的作用是告诉Word“别自动算了就按我给的宽度来”。这句设置往往是列宽不生效问题的关键。还有一个常见需求是表头跨页重复就是表格在第一页有表头到第二页最上面的行还是表头。实现方式是对表头行设置tblHeader标记def set_repeat_table_header(row): tr row._tr trPr tr.get_or_add_trPr() tblHeader OxmlElement(w:tblHeader) tblHeader.set(qn(w:val), true) trPr.append(tblHeader)合并单元格是表格排版的另一个常用操作cell_a table.cell(1, 0) cell_b table.cell(2, 0) merged_cell cell_a.merge(cell_b)合并后如果需要给合并单元格设置内容操作的是merge返回的Cell对象。这里还有个细节合并前最好先统一单元格里的字体格式因为合并本身会把不同区域的XML合并之后再处理格式会更复杂。3.5 图片插入与对齐报告里配图很常见。python-docx插入图片用add_picture但要注意它默认是加在一个独立段落的尾部而且位置取决于光标最后所在位置。常规做法是新建一个段落然后往段落里加图片并设置居中from docx.shared import Cm from docx.enum.text import WD_ALIGN_PARAGRAPH p doc.add_paragraph() p.alignment WD_ALIGN_PARAGRAPH.CENTER run p.add_run() run.add_picture(chart.png, widthCm(14))设置width之后图片高度会按比例自动缩放不会变形。如果你拿到的是网络图片先下载到临时目录再插入注意文件名和路径别带中文和空格某些场景下读取路径会出问题。3.6 页眉页脚和页码的自动化实现页码是长文档必不可少的部分。python-docx本身没有直接提供插入页码的API必须通过域代码fldChar实现。我封装了一个函数可以在页脚里加上居中或右对齐的“第 X 页”def add_page_number(section, alignWD_ALIGN_PARAGRAPH.CENTER): footer section.footer p footer.paragraphs[0] p.alignment align run p.add_run(第 ) add_field(run, PAGE) p.add_run( 页) def add_field(run, field_code): fldChar1 OxmlElement(w:fldChar) fldChar1.set(qn(w:fldCharType), begin) instrText OxmlElement(w:instrText) instrText.set(qn(xml:space), preserve) instrText.text field_code fldChar2 OxmlElement(w:fldChar) fldChar2.set(qn(w:fldCharType), end) run._r.append(fldChar1) run._r.append(instrText) run._r.append(fldChar2)这段代码里最关键的概念是“域”。页码、目录、自动编号在Word里都是域Python要做的就是往XML里写域的开始标记、指令文本和结束标记。文件生成后Word打开会自动计算域的当前值但如果目录类域没有自动刷新就需要用户手动“更新域”或我们通过宏/SDK刷新。页眉内容类似可以在页眉段落中插入公司名称、文档编号、图片Logo。首页不同、奇偶页不同的设置也支持sec.different_first_page_header_footer True。3.7 自动生成目录目录和页码一样都是域。我用类似的方式插入TOC域def add_toc(doc): p doc.add_paragraph() run p.add_run() fldChar1 OxmlElement(w:fldChar) fldChar1.set(qn(w:fldCharType), begin) instrText OxmlElement(w:instrText) instrText.set(qn(xml:space), preserve) instrText.text TOC \\o 1-3 \\h \\z \\u fldChar2 OxmlElement(w:fldChar) fldChar2.set(qn(w:fldCharType), separate) t OxmlElement(w:t) t.text 目录将在打开文档后自动更新 fldChar3 OxmlElement(w:fldChar) fldChar3.set(qn(w:fldCharType), end) run._r.append(fldChar1) run._r.append(instrText) run._r.append(fldChar2) run._r.append(t) run._r.append(fldChar3)TOC域的本质是“根据标题样式自动收集目录条目”。所以前提是文档里的标题必须使用Word内置的Heading 1、Heading 2等样式而不是光把文字加粗放大。很多人的目录生成不了根本原因就是标题没用对样式。python-docx生成的文件里TOC的目录条目不会自动填充需要用户在Word打开时右键“更新域”或我们在流程里调用Word COM进行更新。如果是批量无人值守的场景可以配合pywin32自动刷新后另存这个我后面会提到。4. 进阶场景模板渲染、批量处理和格式转换4.1 用docxtpl做模板渲染比手写段落高效太多上面的操作都是逐段add_paragraph、add_run适合从零构建文档。但实际业务里很多文档是“模板 变量”的模式比如报价单、合同、录用通知书。这种场景我强烈推荐docxtpl它把Jinja2模板语法和docx结合起来允许你在Word里编辑模板用{{ customer_name }}、{{ total_amount }}这类占位符标记可变位置然后在Python里传入数据一次渲染。from docxtpl import DocxTemplate doc DocxTemplate(template.docx) context { customer_name: 某某科技有限公司, product_items: [ {name: 运维服务, price: 12000}, {name: 安全评估, price: 8000} ], } doc.render(context) doc.save(output.docx)docxtpl最大的价值是把“排版”和“数据”解耦。排版工作交给熟悉Word的人去设计模板Python工程师只需要维护数据字典。模板里的循环用{% for item in product_items %}包裹复杂表格也能实现自动扩展。不过要注意docxtpl对中文支持很好但模板里的runs结构不能太乱一个段落如果被Word拆成多个run模板变量可能会出现渲染异常我习惯把占位符单独放在一个段落里避免和其他文字混排。4.2 批量生成上百份带编号的文档批量生成的核心是循环 数据源。数据源可以用pandas读取Excel也可以用数据库查询结果。每次循环时用客户编号或者唯一字段作为文件名同时对文件名里的非法字符做清洗避免保存失败import pandas as pd from docx import Document df pd.read_excel(customers.xlsx) for idx, row in df.iterrows(): doc Document(report_template.docx) # 填充内容逻辑 doc.save(freport_{row[客户编号]}.docx)这种批量场景中最常见的性能问题是样式设置太细太碎每条记录都要调用大量run级格式操作导致生成慢。我的经验是样式相同的部分尽量在模板里预先定义好代码只做数据填充实在需要代码控制格式的抽成公共函数不要在主循环里写一堆重复的格式代码。4.3 Markdown 转 Word 的工作流搜索热词里出现了“markdown转word工作流coze”这确实是内容生产和办公场景很常见的一条链路。Markdown轻量好写但最终交付给客户或领导的往往是格式规范的Word。最省力的方案是用pandocpandoc input.md -o output.docx --toc --highlight-styletangopandoc能把标题、列表、代码块、表格甚至图片都转成Word原生对象标题自动映射到Heading样式--toc可以生成目录。但它的默认样式比较朴素中文文档生成后可能需要再调整中文字体和页边距。所以我的常见做法是pandoc负责结构转换然后继续用python-docx对生成的docx做二次美化统一字体、设置首行缩进、调整间距。这也是“Markdown写内容、Python做排版”的高效组合。如果你不想安装pandoc也可以自己写一个markdown解析器把#、-、表格语法映射到python-docx对应API但成本比pandoc高不少适合有特殊定制需求的情况。4.4 关于 PDF 转 Word别抱太高期望“pdf转word”是一个搜索量极高的词但说实话这条路处理起来远比生成docx痛苦。PDF本身是为展示设计的不是为编辑设计的尤其是扫描件、图片型PDF原生根本没有任何文本信息转出来必然是灾难。如果你手头是文本型PDF可以试试先用pdfplumber或PyMuPDF把文字和坐标提取出来再按顺序填入docx。但格式还原度取决于源文件的质量原PDF如果排版复杂、有图文混排转出来的Word通常需要大量手工修正。我的建议是能用AI直接生成结构化的Markdown或docx模板就不要走PDF转Word这条路。PDF转Word只是一个兜底手段千万别把它当成稳定的自动化方案。5. 常见问题与排查技巧实录5.1 Word 关闭时卡顿、关闭很慢怎么排查这个问题在热词里反复出现确实和自动化办公高度相关。很多时候Python脚本用pywin32操作完Word后没有正确释放进程WINWORD.EXE会一直残留在后台。下次用户手动打开Word系统会尝试加载之前残留的会话状态导致启动和关闭都异常缓慢。使用pywin32时务必保证每个COM对象的释放import win32com.client import pythoncom word win32com.client.Dispatch(Word.Application) word.Visible False try: doc word.Documents.Open(rD:\report.docx) # 执行操作 doc.Close(SaveChangesFalse) finally: word.Quit() win32com.client.Release()另外如果发现Word关闭特别慢先打开任务管理器检查有没有多个WINWORD.EXE进程全部结束掉再尝试关闭文档时取消“加载项”和“自动保存”的干扰。还有些机器是因为安装了过多的Word加载项比如各种公式编辑器插件这类问题只能通过禁用非必要加载项来解决。5.2 表格列宽设置不生效、无法拖动表格列宽问题我在3.4已经详细说过了核心就是自动调整和固定布局的冲突。如果你生成的表格在Word里“列宽无法拖动”先看表格属性是否勾选了“自动调整列宽”。python-docx生成的表格如果没显式设置tblLayout默认可能被Word自动重算。遇到这种问题我的排查顺序是先确认每个cell.width都设置到位再确认tblLayout设置为固定最后检查是不是自定义样式表里覆盖了列宽属性。多数情况下前两步就能解决。5.3 中文字体、音标和特殊字体显示异常排版文档时经常要处理黑体、宋体、仿宋、楷体有时候还要输入英语音标。中文字体缺失会有字体替换提示英语音标缺失则可能显示成方框。音标字符建议大家使用系统自带的“尤特”或者安装Doulos SIL一类的专门字体并在脚本里预先设置run的字体不要依赖默认字体。如果你在Word里手动打音标也不正常往往是输入法或字体问题可以用Unicode码位直接插入run.add_text(\u02c8)这种方式强制写入正确的音标字符。5.4 公式和特殊对象无法直接生成python-docx对公式、数学对象、文本框、艺术字这类复杂对象的支持非常有限。需要在Word里插入公式的话我的首选方案是pywin32直接操作Word应用插入公式然后保存。还有一种思路是提前在模板Word里放好公式作为占位内容然后在数据填充时只替换公式周围的可变文字不触碰公式本身。关于MathType一个很常见的现象是“MathType插入Word提示没有找到需要转换的公式”。这通常是因为Word里的公式不是内嵌图片而是OLE对象Word需要找到MathType的DLL去唤醒编辑。遇到这种情况要么重装MathType并勾选Word插件要么用Word自带的公式编辑器写一遍。在自动化流程里我尽量不使用MathType统一用Word原生公式样式兼容性更稳定。5.5 宏安全、docx兼容性和版本差异生成docx文件时要考虑目标用户的Word版本。旧版Office或WPS对某些样式属性的解释不一样比如页面边框、主题字体、表格布局。我一般会在交付前用WPS和Office各打开一次检查渲染效果。如果发现样式差异很大就减少对主题颜色和特殊样式的依赖尽量使用显式颜色值。有些企业环境默认禁用宏这会影响两步操作一是pywin32无法执行需要宏的刷新操作二是docx里如果带了自定义宏文件会被拦截。如果只是需要更新目录域可以用pywin32单独执行一次“更新所有域”然后另存为不带宏的普通docx不影响目标文档的使用。6. 完整实例从Excel数据生成报价单最后分享一个完整的迷你项目。它有两条输入一个是Excel报价明细表字段包括产品名称、数量、单价、备注另一个是报价单模板的结构要求公司名称、报价日期、表格、总金额、页脚页码。目标是一次生成一个排版合格的Word报价单。先定义公共的字体和格式工具函数然后把数据读出来创建工作区目录循环生成并保存import pandas as pd from docx import Document from docx.shared import Pt, Cm from docx.enum.text import WD_ALIGN_PARAGRAPH from docx.enum.table import WD_TABLE_ALIGNMENT from docx.oxml.ns import qn from docx.oxml import OxmlElement def set_run_font(run, cn_font宋体, sizePt(12), boldFalse): run.font.name Times New Roman rPr run._element.get_or_add_rPr() rFonts rPr.find(qn(w:rFonts)) if rFonts is None: rFonts OxmlElement(w:rFonts) rPr.append(rFonts) rFonts.set(qn(w:eastAsia), cn_font) run.font.size size run.font.bold bold def add_centered_paragraph(doc, text, cn_font宋体, sizePt(12), boldFalse): p doc.add_paragraph() p.alignment WD_ALIGN_PARAGRAPH.CENTER run p.add_run(text) set_run_font(run, cn_fontcn_font, sizesize, boldbold) return p df pd.read_excel(quote_data.xlsx) for _, row in df.iterrows(): doc Document() sec doc.sections[0] sec.page_width Cm(21.0) sec.page_height Cm(29.7) sec.left_margin Cm(2.0) sec.right_margin Cm(2.0) add_centered_paragraph(doc, f报价单 - {row[客户名称]}, cn_font黑体, sizePt(16), boldTrue) add_centered_paragraph(doc, f日期{row[报价日期]}, sizePt(11)) table doc.add_table(rows1, cols5) table.style Table Grid table.alignment WD_TABLE_ALIGNMENT.CENTER headers [产品名称, 数量, 单价, 金额, 备注] for idx, header in enumerate(headers): cell table.cell(0, idx) cell.text p cell.paragraphs[0] p.alignment WD_ALIGN_PARAGRAPH.CENTER run p.add_run(header) set_run_font(run, cn_font黑体, sizePt(10), boldTrue) total 0 for j in range(int(row[产品数量])): item row[产品名称] if j 0 else qty row[数量] if j 0 else price row[单价] if j 0 else amount row[数量] * row[单价] if j 0 else 0 total amount if j 0 else 0 cells table.add_row().cells for k, val in enumerate([item, qty, price, amount, ]): p cells[k].paragraphs[0] p.alignment WD_ALIGN_PARAGRAPH.CENTER run p.add_run(str(val)) set_run_font(run, sizePt(10)) # 设置固定布局及列宽 tblPr table._tbl.tblPr layout OxmlElement(w:tblLayout) layout.set(qn(w:type), fixed) tblPr.append(layout) widths [Cm(5.0), Cm(2.0), Cm(2.5), Cm(3.5), Cm(3.5)] for r in table.rows: for idx, c in enumerate(r.cells): c.width widths[idx] add_centered_paragraph(doc, f总金额{total} 元, cn_font宋体, sizePt(12), boldTrue) # 页脚页码 footer sec.footer fp footer.paragraphs[0] fp.alignment WD_ALIGN_PARAGRAPH.CENTER r1 fp.add_run(第 ) add_field(r1, PAGE) fp.add_run( 页) doc.save(foutput/报价单_{row[客户名称]}.docx)这个实例覆盖了本篇文章讲的大部分内容页面设置、中文字体、表格样式、固定列宽、页脚页码。跑一遍这个脚本你就等于把这套流程完整过了一遍。真实项目里再根据自己的业务需求往里面加Logo、条款、审批框等模块就行。做Word自动化这行我个人最大的体会是一定要先去理解Word的底层模型再考虑用什么库。很多人上来就搜代码复制粘贴结果换一种字体就失效换一种表格就错乱归根结底是没有理解Paragraph、Run、XML域这些概念。花半天时间把原理搞清楚后面能少加一个月的班。最后再分享一个小技巧不要一上来就写完整代码先用几十行脚本生成一个最小的docx解压看XML亲眼看看“段落、run、属性”在XML里长什么样建立这个直觉之后你写所有排版脚本都会顺畅很多。