企业官网建设流程全解析

1. 为什么我最后选了 MHTML 这条路

先说结论：如果你手上有一个已经渲染好的页面，想在不碰后端、不装 Office、不引入重型文档库的前提下，导出一份"打开就是原样"的 Word 文档，那么 MHTML 打包这条路的性价比是最高的。它不需要你重新描述一遍文档结构，也不要求你把每个元素翻译成 OOXML 的节点，只需要把浏览器已经渲染出来的 HTML 连同图片一起"封"进一个文件里，Word 自己会去解析它认识的那部分。

这套思路我在两个后台系统里用过，一个是用 Vue 写的报表中心，一个是用原生 JS 写的巡检记录页。两边都有同样的诉求：用户在页面上看到什么，导出的 Word 就得是什么，字体、颜色、表格线、图片位置不能走样。之前也试过让后端用模板引擎生成，结果每次风格微调都要前后端一起改，改完还要等发版，来回一趟半天就没了。后来把导出这件事完全挪到前端，问题就变成了纯技术问题，反而清爽。

1.1 需求起点：一个纯前端的导出按钮

这个需求的源头通常特别朴素——页面右上角加一个"导出 Word"按钮。听起来很简单，但真正麻烦的地方在于"保留原来显示的样式"这七个字。页面上用的是 CSS 变量、flex 布局、圆角阴影、渐变背景，这些在浏览器里天经地义的东西，到了 Word 里大部分会失效。Word 的排版引擎是流式的，它理解的是段落、行、表格单元格，而不是盒模型和层叠上下文。

所以"保留样式"必须重新定义边界：不是像素级复刻，而是把可迁移的视觉特征——字体、字号、字重、颜色、对齐、缩进、边框、表格结构、图片尺寸和位置——完整搬过去。这些恰好都是 Word 的 HTML 导入器能认的东西。想清楚这条线，后面所有取舍都有了依据，也就不会陷进"为什么我的阴影没了"这种无解的纠结里。

另外还要明确一点：导出的是"文档"而不是"截图"。有些同学图省事，直接 canvas 截图塞进 Word，结果是里面文字不能选、不能搜、打印发虚、文件还巨大。这条路在只做归档的场景下能用，但只要有二次编辑需求就废了，所以我从一开始就没考虑。

1.2 三条技术路线的对比与取舍

在动手之前我把当时能想到的方案列了个表，逐条权衡之后才定的方向。这里把对比结论直接放出来，你可以少走一遍弯路。

取舍的关键点有两个。一是"谁来承担样式映射的成本"，docx.js 那条路等于把 CSS 重新翻译成文档对象模型，页面越复杂成本越高，而且是持续的维护成本。二是"图片怎么办"，只要涉及图片，就绕不开跨域和二进制转换，MHTML 的分段机制天然解决这个问题，图片作为独立部件挂在同一个文件里，不需要额外的下载逻辑。

我最后选 MHTML，核心理由是它把"渲染"这件事交给浏览器，把"解析"交给 Word，中间我只做搬运。这个分工让代码量压到了两百行以内，而且页面改样式不用改导出逻辑，这是最实在的收益。

1.3 MHTML 方案的能力边界，先想清楚再动手

用之前必须知道它做不到什么，否则上线之后会被用户投诉淹没。

做不到的第一类是布局级效果。flex、grid、绝对定位、transform、动画、阴影、滤镜、伪元素装饰，这些在 Word 里全部无效或者会被降级成普通块。第二类是交互相关的东西，按钮、下拉框、滚动条、hover 状态不会被导出，这个反而是好事，导出前通常要把这些隐藏掉。第三类是部分现代 CSS 语法，比如 CSS 变量在多数 Word 版本里不生效，rem 和 vh 也指望不上，这些必须在内联化阶段换算成具体的 px 或 pt。

能保住的部分比想象中多：字体族、字号、粗体斜体、文字颜色、背景色、段落的对齐和缩进、行高、列表符号、表格的整体结构、单元格的边框和底色、合并单元格、图片的宽高和对齐。这些覆盖了绝大多数公文、报表、记录单的排版需求，也正好是用户在意的部分。

我的建议是先在纸上列一份"必须保留"和"可以放弃"的清单，把清单交给产品确认一遍。这一步看着多余，实际上能省掉后面九成的返工。我第二次做这个功能时，就是因为提前确认了"阴影和圆角可以不保留"，才没有在无解的问题上浪费两天。

2. 核心原理：Word 眼中的 HTML 长什么样

搞清楚原理，很多"玄学失效"就有解释了。Word 从很早就内置了 HTML 导入能力，它的解析器本质上是一个把 HTML 标签映射成内部文档节点的翻译器，同时会读取一部分 CSS。这个解析器对标准的遵循程度停留在早期阶段，支持的是一个裁剪过的子集，而且很多能力是通过mso-前缀的私有属性暴露出来的。

另外一个关键点是文件格式。Word 并不要求 HTML 必须独立存放，它支持一种叫 MHTML 的封装格式，也就是把 HTML 和它引用的所有资源打包成一个多部件文件。这个格式规范其实是通用的 MIME 多部分消息，只不过扩展名用了.doc，系统就会用 Word 打开。理解了这两点，代码就非常好写了。

2.1 MHTML 其实就是一封"多部件的邮件"

把 MHTML 想象成一封带多个附件的电子邮件就通了。整份文件由若干"部件"组成，每个部件之间有分隔线，每个部件自己带一段头部信息，声明自己的类型和位置，然后是内容本体。第一个部件放 HTML 文本，后面的部件依次放图片、样式表之类的外部资源。

部件的顺序有个约定：主文档排在第一位，Word 会把它当作入口，其余部件按需被引用。每两个部件之间用一行------=_NextPart_XXX这样的分隔线隔开，结尾处再补一个带两个短横线的结束标记。_NextPart_XXX这个字符串必须在整个文件里唯一，一般用时间戳加随机数拼出来，避免和正文内容撞车。

每个部件头部里最重要的是Content-Location，它是这个部件在文件内部的"地址"，图片的src写的就是这个地址，两边必须完全对应上，差一个字符图片就显示不出来。我见过最常见的失败案例就是这里拼错了，或者在拼接时多了一个空格。

2.2 Word 的 HTML 解析器只认一个 CSS 子集

这个子集大致可以这么记：能按"盒子里的东西"来理解，但不能按"盒子外面怎么摆"来理解。也就是说，文字本身的属性、背景、边框、内边距、表格单元格的属性，这些都能读；而元素之间怎么排列、怎么定位、怎么叠放，它基本不管，它按自己的流式规则重新排一遍。

具体到常用属性，我列一份实际验证过的清单，照着用基本不会踩空：

• 文字：font-family、font-size、font-weight、font-style、color、text-decoration
• 段落：text-align、text-indent、line-height、margin、padding
• 边框：border、border-collapse，建议写成完整的四边简写
• 表格：width、height、background-color、vertical-align、text-align
• 列表：list-style-type，但嵌套层级多了容易错乱，我一般直接手动加编号更稳
• 图片：width、height，强烈建议同时写成 HTML 属性

不生效的清单也很固定：position、z-index、display: flex、display: grid、float在复杂场景下、transform、box-shadow、border-radius、filter、transition、animation。另外rem、em、vh、vw这些相对单位在换算环节最好都落地成px或pt，别指望 Word 会帮你算。

2.3 图片为什么必须走 MIME 分段而不是 data URI

很多人第一反应是 base64 内联，写成data:image/png;base64,...。这个做法在浏览器里没问题，在 Word 里就分版本了。较新的版本能认，一些老版本和一些 WPS 版本会直接显示成空白或者红叉。原因在于 Word 对 data URI 的支持是后加的，早期解析器看到这种形式会当作未知协议直接跳过。

所以稳妥做法是走 MIME 分段：每张图片作为独立部件，Content-Location写成一个file:///风格的地址，比如file:///C:/temp/export/image001.png，HTML 里的src写同一个地址。这样无论新旧版本都能正常加载。虽然看起来有点笨，但兼容性上的收益非常明显，我后来再没遇到过图片丢失的反馈。

顺便说一句，图片体积会膨胀大约三分之一，这是 base64 编码的固有代价。一张 200KB 的 PNG 编码后大概 270KB。如果文档里有大量图片，可以在导出前统一做一次压缩和尺寸裁剪，把宽度限制在文档实际显示宽度以内，这样能省下非常可观的空间。

3. 动手实现：从 DOM 到可下载的 .doc

原理讲完就进入实操。整个流程我拆成四步：固化样式、处理资源、拼装文本、触发下载。每一步都有几个必踩的坑，我按实际写代码的顺序讲，你可以直接对着改。

先说明一下运行环境。这套代码是纯浏览器端的，不需要任何构建工具，原生 JS 就能跑，放到 Vue 或 React 项目里也只需要把 DOM 获取那一段换掉。浏览器方面，现代版本都能支持，Safari 在下载那一步需要特殊处理，后面会讲。

3.1 第一步：把页面样式"固化"下来

这一步是决定最终效果的核心。页面上大量样式来自外部样式表、CSS 变量、类和伪类，Word 读不到这些，必须把它们变成元素自身的内联样式。

我的做法是深度克隆待导出节点，然后遍历克隆体里的所有元素，用getComputedStyle把计算后的样式逐条写进style属性。这里不要贪心，把所有 CSS 属性都抄一遍会让体积暴涨而且拖慢速度，我只挑前面清单里列出的那几十个白名单属性。

const STYLE_WHITELIST = [ 'font-family', 'font-size', 'font-weight', 'font-style', 'color', 'text-align', 'text-indent', 'line-height', 'margin-top', 'margin-bottom', 'margin-left', 'margin-right', 'padding-top', 'padding-bottom', 'padding-left', 'padding-right', 'background-color', 'border-top', 'border-bottom', 'border-left', 'border-right', 'border-collapse', 'vertical-align', 'width', 'height', 'list-style-type' ]; function inlineStyles(source) { const clone = source.cloneNode(true); const srcNodes = source.querySelectorAll('*'); const cloneNodes = clone.querySelectorAll('*'); for (let i = 0; i < cloneNodes.length; i++) { const computed = getComputedStyle(srcNodes[i]); const target = cloneNodes[i]; target.removeAttribute('class'); target.removeAttribute('id'); STYLE_WHITELIST.forEach(function (prop) { const value = computed.getPropertyValue(prop); if (value && value !== 'none' && value !== 'normal') { target.style.setProperty(prop, value); } }); } return clone; }

有两点要注意。第一，getComputedStyle读到的尺寸是 px，比如font-size会返回16px，这个单位 Word 能接受，换算比例是 1px 等于 0.75pt，所以 16px 就是 12pt，正好是常用的正文小四号，这个巧合让字体映射变得很省事。第二，克隆体和原节点的子元素顺序必须严格一致，querySelectorAll返回的是文档顺序，两边一一对应，这点是可以放心的，但如果你的页面里有动态生成的节点，最好在导出前先确保 DOM 稳定。

如果页面里有伪元素画出来的装饰，比如用::after画的分隔线，这一步是抓不到的。处理办法是在导出前把它们隐藏，或者用真实的元素替代，我一般选后者，改起来更直观。

3.2 第二步：处理图片与外部资源

图片是第二个大坑。页面上的图片可能是同源的、跨域的、懒加载的、CSS 背景的、SVG 的，处理方式各不相同。

同源图片最省事，用fetch拿到 blob 再转成 base64 就行。跨域图片会直接失败，除非对方允许跨域，否则只能把图片转成 canvas 再导出，但 canvas 又要求图片本身可跨域读取，绕不开。我的经验是：能控制在同源就用同源，如果确实来自其他域，让后端加一层代理或者在图片上传时就统一存到自己的存储服务上，比在前端硬解要干净得多。

async function imageToBase64(src) { const response = await fetch(src); const blob = await response.blob(); return new Promise(function (resolve, reject) { const reader = new FileReader(); reader.onload = () => resolve(reader.result.split(',')[1]); reader.onerror = reject; reader.readAsDataURL(blob); }); }

CSS 背景图要单独处理，因为它是写在样式里的url(...)，需要正则扫出来替换。我的做法是在内联化之前，先把背景图统一取出来转成<img>元素插进文档流，这样既能控制位置，又能走同一套图片处理逻辑，比在 CSS 里硬改要稳。

SVG 要特别注意。直接作为图片引用时，部分 Word 版本渲染会出错。保守做法是在导出前把 SVG 转成 PNG，用 canvas 画一遍再取 base64。如果文档里 SVG 很多，转换会明显拖慢导出速度，这个时候加个进度提示体验会好很多。

3.3 第三步：拼装 MHTML 文本

这一步就是把 HTML 和图片部件拼成一个字符串。头部信息先定下来，然后按部件依次拼。

function buildMhtml(htmlContent, images) { const boundary = '----=_NextPart_' + Date.now() + '_' + Math.random().toString(36).slice(2); const base = 'file:///C:/export/'; let parts = []; parts.push( 'MIME-Version: 1.0\n' + 'Content-Type: multipart/related; boundary="' + boundary + '"\n\n' ); parts.push( '--' + boundary + '\n' + 'Content-Location: ' + base + 'document.html\n' + 'Content-Type: text/html; charset="utf-8"\n' + 'Content-Transfer-Encoding: quoted-printable\n\n' + htmlContent + '\n\n' ); images.forEach(function (img, index) { const name = 'image' + String(index + 1).padStart(3, '0') + '.' + img.ext; parts.push( '--' + boundary + '\n' + 'Content-Location: ' + base + name + '\n' + 'Content-Type: image/' + img.ext + '\n' + 'Content-Transfer-Encoding: base64\n\n' + img.base64 + '\n\n' ); }); parts.push('--' + boundary + '--'); return parts.join(''); }

两个细节值得单独说。Content-Transfer-Encoding我写的是quoted-printable，但实际内容没有做编码转换，这在大多数情况下能正常工作，因为正文里基本是 ASCII 标签加 UTF-8 中文，配合 charset 声明就够了。如果你的内容里出现了大量特殊字符导致解析异常，把这一行改成8bit往往更稳，这是我实测出来的经验。

另一个是base路径。它只是个逻辑地址，文件不存在也没关系，Word 加载时按部件内的Content-Location匹配，不依赖真实文件系统。但 HTML 里的src必须和它完全一致，所以我在内联化之后会统一遍历一遍所有img，把src替换成base + name，这一步千万不能漏。

3.4 第四步：生成 Blob 并触发下载

最后一步看着最简单，其实是兼容性问题最集中的地方。

function downloadDoc(mhtml, filename) { const blob = new Blob(['\ufeff', mhtml], { type: 'application/msword;charset=utf-8' }); const url = URL.createObjectURL(blob); const link = document.createElement('a'); link.href = url; link.download = filename.endsWith('.doc') ? filename : filename + '.doc'; document.body.appendChild(link); link.click(); document.body.removeChild(link); setTimeout(function () { URL.revokeObjectURL(url); }, 1000); }

那个\ufeff是 BOM，别省略。加了之后 Word 才会按 UTF-8 解析，不加的话中文在部分环境下会变成乱码，这是最常见的乱码原因，跟编码本身没关系。type用application/msword，配合.doc扩展名，系统就能把文件关联到 Word。

扩展名这里有个小选择。用.doc兼容性最好，双击直接打开。用.mht也不错，但有些用户会困惑这是什么格式。我一般用.doc，然后在界面上给个提示说明这是 HTML 格式的文档，可编辑但结构相对简单，提前打个预防针能减少很多解释成本。

Safari 的处理稍特殊，它对download属性的支持历史上有过反复，稳妥做法是加一个msSaveBlob判断兜底，或者直接在新窗口打开让用户自己保存。如果你的用户群里 Safari 占比不低，这块务必实测一遍。

3.5 完整可运行的代码骨架

把上面四步拼起来，主流程大概是这样。

async function exportToWord(element, filename) { const clone = inlineStyles(element); const imgNodes = clone.querySelectorAll('img'); const images = []; const base = 'file:///C:/export/'; for (let i = 0; i < imgNodes.length; i++) { const src = imgNodes[i].getAttribute('src'); if (!src) continue; const base64 = await imageToBase64(src); const ext = src.split('.').pop().split('?')[0] || 'png'; const name = 'image' + String(i + 1).padStart(3, '0') + '.' + ext; images.push({ base64: base64, ext: ext }); imgNodes[i].setAttribute('src', base + name); imgNodes[i].removeAttribute('srcset'); } const html = wrapDocument(clone.outerHTML); const mhtml = buildMhtml(html, images); downloadDoc(mhtml, filename); }

其中wrapDocument负责补上html、head、meta charset和一段基础样式，包括页面尺寸和默认字体。这段包装很容易被忽略，但它是控制整体版式的入口，下一章会详细讲。整个流程在中等复杂度的页面上耗时通常在几百毫秒，图片多的话会到一两秒，加个 loading 遮罩很有必要。

提示：如果导出按钮点下去没反应，八成是某张图片的fetch抛异常把整个链路中断了。给图片处理单独套try/catch，失败的图片降级成一个占位符，比整个导出失败要友好得多。这个细节我在第一次上线时没做，结果一个跨域头像让所有用户都导不出来。

4. 样式保真的细节：尺寸、字体与分页

到这里功能已经能跑通了，但离"打开就是原样"还差一层。这一章讲的全是让效果从"能看"变成"专业"的细节，每一条都是实际调出来的。

4.1 A4 纸张与页边距的换算

Word 默认纸张是 A4，尺寸 210mm 乘 297mm。CSS 里最方便的单位是 pt，换算关系是 1mm 约等于 2.8346pt，所以 A4 就是 595.28pt 乘 841.89pt。这个页面尺寸要在包装文档的样式里明确写出来，否则 Word 会按默认的 Letter 或者根据内容自适应，打印出来就错位了。

页边距方面，常规公文是上下 2.54cm、左右 3.17cm，换算成 pt 是上下 72pt、左右 90pt。如果是内部记录单，四边留 2cm 也就是 56.7pt 就够。这里的关键是，页边距必须在@page规则里声明，写在body的margin上是不起作用的，这是两回事。

<style> @page WordSection1 { size: 595.28pt 841.89pt; margin: 72pt 90pt 72pt 90pt; mso-page-orientation: portrait; } div.WordSection1 { page: WordSection1; } </style>

然后正文内容要包在<div class="WordSection1">里，这个类名和@page的名字必须对上，对不上页边距就不生效。另外mso-page-orientation控制纸张方向，横向表格多的时候会用到。这套写法看着有点老旧，但它是 Word 真正认的语法，别嫌弃。

4.2 字体、字号、行高的映射表

字号是最容易出问题的地方。浏览器里font-size算出来是 px，Word 里按 pt 理解，1px 等于 0.75pt。中文文档常用字号和 px 的对应关系我整理了一份，直接抄着用就行。

行高要特别提醒。浏览器里line-height: 1.5这种无单位写法会返回计算后的具体 px，Word 能认。但如果返回的是normal，Word 会用自己的默认行距，通常是 1.15 倍左右，和页面显示会有出入。所以行高建议统一写成明确的 px 或百分比，别留normal。

字体族也有讲究。写font-family时最好按"具体字体 + 通用族"的顺序，比如"微软雅黑", "Microsoft YaHei", sans-serif。中文字体名和英文名都写上，不同系统识别的不一样。如果原文用的是系统没有的字体，Word 会回退到默认字体，这种情况下版式宽窄会有明显变化，必要时把字体文件也作为资源打包进去，但这会显著增大体积。

4.3 表格列宽与边框的固定策略

表格是最容易翻车的地方，因为它涉及列宽这个敏感属性。常见现象是：明明在页面上比例正常，导出后某一列变得特别宽或者特别窄，用户想拖也拖不动。

原因在于 Word 对表格宽度的判定逻辑和浏览器不同。浏览器会综合考虑内容、min-width、table-layout，Word 则更依赖显式声明的宽度。解决办法有两条，我一般都是两条一起上。

第一条是给表格加table-layout: fixed，同时每个单元格都写上明确的宽度值，单位用 pt。第二条是在table标签里用colgroup声明列宽，Word 对colgroup的支持很好，优先级也高。

<table style="table-layout: fixed; border-collapse: collapse; width: 450pt;"> <colgroup> <col style="width: 60pt;"> <col style="width: 200pt;"> <col style="width: 100pt;"> <col style="width: 90pt;"> </colgroup> <tr> <td style="border: 1pt solid #000; padding: 4pt 6pt;">序号</td> <td style="border: 1pt solid #000; padding: 4pt 6pt;">名称</td> <td style="border: 1pt solid #000; padding: 4pt 6pt;">数量</td> <td style="border: 1pt solid #000; padding: 4pt 6pt;">备注</td> </tr> </table>

边框一定写成四边简写，别只写border-bottom，Word 有时候会漏掉一部分。另外border-collapse: collapse必须加，否则会出现双线。单元格内边距用padding就行，Word 能识别，但上下内边距建议小一点，4pt 到 6pt 比较合适，太大表格会撑得很高。

关于列宽拖动，还有个隐藏因素：如果给表格设了固定的总宽度且各列都写死了，Word 会把表格锁定为固定布局，用户拖动列宽时确实会受限。这是预期行为，不是 bug。如果确实需要用户可调，就把总宽度去掉，只保留最小宽度，让 Word 用自动布局。两种模式各有用途，看你的场景需求。

4.4 分页控制与页眉页脚

分页这件事，浏览器里没有概念，Word 里却很在意。默认情况下内容会一直流下去，在任意位置断开，可能出现一行标题孤零零留在页尾的尴尬情况。

控制手段主要是page-break-before和page-break-after。给一级标题加page-break-before: always，每个章节就自动另起一页，这在报告类文档里很常用。给表格的行加page-break-inside: avoid，可以防止一行被拦腰截断。

h2 { page-break-before: always; } table tr { page-break-inside: avoid; } h2, h3 { page-break-after: avoid; }

page-break-after: avoid用在标题上，能保证标题不会单独落在页面底部，这个技巧很实用，尤其是有多级标题的长文档。不过要注意，它在表格内部的标题上效果有限，遇到问题还是手动加空的段落更直接。

页眉页脚在 MHTML 里支持得比较有限，能做但很别扭。可以通过@page里的mso-header相关属性声明，复杂一点的需要用div模拟。我的建议是：如果页眉页脚只是文字加页码，可以考虑放弃，让用户在 Word 里手动设置一次，比在前端折腾半天要划算。如果确实必须自动带，那就用简单方式实现，别追求复杂的样式，否则维护成本会远超收益。

5. 常见问题排查实录

做了几轮之后，我把遇到过的问题整理成了一份速查清单。这一章基本是踩坑记录的浓缩版，遇到问题可以直接对照着定位。

5.1 图片丢失、中文乱码、Word 报错

图片全是红叉或者空白。九成是Content-Location和src不一致导致的。排查方法很简单，把导出的文件用文本编辑器打开，搜一下Content-Location，看看每个图片部件声明的地址，再搜 HTML 里的src，逐条核对。另外要确认图片部件出现在 HTML 部件之后，顺序不对也可能加载不出来。

中文变乱码。三个检查点：Blob 前面加没加 BOM，Content-Type里写没写charset="utf-8"，HTML 的meta charset是否声明。三个都对还乱码，就把Content-Transfer-Encoding从quoted-printable换成8bit，这一招解决过我遇到的大部分顽固乱码。

打开时提示文件损坏或者无法打开。通常是分隔符写错了。常见错误是结束标记少写两个短横线，或者两个部件之间少了一个换行，或者 boundary 字符串里出现了不该有的空格。这种问题肉眼不好找，建议在拼接时统一用\n而不是\r\n，并且每个部件结尾固定补两个换行，形成规律之后就不容易出错了。

5.2 样式大面积失效的定位方法

样式没生效的时候别急着改代码，先做个最小化验证：写一个只有一行文字加一个表格的测试页面，导出来看效果。如果这个能正常，那问题就出在复杂样式上；如果这个都不对，那就是包装文档或者 MHTML 结构有问题，方向完全不同。

定位到复杂样式之后，按照"文字属性、段落属性、表格属性、图片属性"四类逐个二分排查。我一般的顺序是先看字体和颜色，这两个最容易一眼看出问题；再看表格，表格结构错了会连累整体；最后看图片。

有一个特别容易被忽略的点：display属性。如果页面大量使用display: flex做布局，内联化之后这些属性会被写进样式里，Word 不认识就会退回默认的块级行为，导致元素全部竖着堆起来。解决办法是在白名单里干脆不要display，或者对那些已知的容器元素在导出前手动改成display: block，配合宽度和浮动来还原大致的横向排布。这一步做不到完美，但比全部堆叠要好得多。

5.3 文件体积与打开速度

体积问题主要来自图片，这是必然的。除了前面说的压缩和裁剪，还有两个可以做的优化：一是过滤掉尺寸过小的装饰性图片，比如一两个像素的分隔线，这些完全可以改由边框实现；二是对于重复出现的图片，比如多个条目共用同一个图标，只打包一份，其余位置引用同一个Content-Location，能省下相当可观的空间。

打开变慢的情况，除了体积，还有一个原因是样式内联后 HTML 变得很长。如果页面元素数量达到几千个，getComputedStyle的遍历本身就是个性能瓶颈，可能要几秒钟。这时候可以分批处理，用requestIdleCallback分片执行，同时给用户一个进度反馈。我在一个长列表页面上做过这个处理，从卡死三秒优化到有进度条的渐进显示，体验差别非常大。

还有一种情况是 Word 在打开时反复计算分页导致的卡顿，这个和内容结构有关。表格嵌套层数多、行数多、跨页频繁，都会加重这个负担。能扁平化的表格尽量扁平化，避免三层以上的嵌套，这在设计页面时就应该考虑。

5.4 问题速查表

把上面的内容浓缩成一张表，遇到问题先扫一眼。

注意：每次改完导出逻辑，一定要在真实的 Word 里打开验证一遍，不要只看下载下来的文件大小。很多问题比如边框丢失、列宽偏移，只有打开文档才能发现，浏览器预览是看不出来的。

6. 工程化落地与进阶玩法

功能做完只是第一步，真正要长期用下去，还得考虑怎么和现有项目融合、怎么复用、怎么演进。这一章聊聊落地层面的经验。

6.1 与 Vue / React 组件集成

在框架里集成，最容易踩的坑是响应式数据和真实 DOM 的差异。虚拟 DOM 上的节点属性并不是最终渲染结果，getComputedStyle必须作用在真实的 DOM 元素上，所以一定要用ref或者querySelector拿到实际元素，而不是从 props 或者 state 里拼 HTML。

我的做法是封装成一个独立模块，对外只暴露一个函数，接收元素引用和文件名，内部完全自包含。在 Vue 里这样调用：

const reportRef = ref(null); function handleExport() { exportToWord(reportRef.value, '月度报告').catch(function (err) { console.error('导出失败', err); }); }

组件卸载的时候记得把定时器和未完成的请求清掉，否则可能出现内存泄漏。另外导出前建议先把界面上的操作按钮、加载动画、提示条这些非文档内容隐藏掉，用一个临时的类名批量控制，比在导出逻辑里逐个判断要干净。我一般加一个.export-hidden { display: none !important; }，导出前给这些元素挂上，导出后移除，简单可靠。

如果项目里有多处需要导出，可以把这套逻辑抽成一个通用包，把白名单、包装文档、图片处理都做成可配置的，不同页面通过配置来适配自己的样式需求。这个抽象做一次，后面每加一个导出点几乎零成本。

6.2 批量导出与模板复用

有些场景需要一次导出多份，比如每个部门一份报表。这时候有两个思路：一是循环调用，每份生成一个文件依次下载；二是把所有内容合并到一个文档里，用分页符隔开。

循环下载的问题是浏览器会连续弹多个下载提示，体验不太好，有些浏览器还会拦截。合并成单文档更稳妥，但要注意每份内容都要有独立的页面设置，通过多个@page规则来实现，规则名和对应的div类名一一对应就行。这样一份文件里可以包含横向和纵向混排的页面，这在报表场景里很有用。

模板复用指的是把包装文档、白名单、样式映射这些配置抽出来，做成配置文件。我现在的做法是把常用的几种文档类型各写一份配置，比如"公文格式"用宋体三号加固定页边距，"内部记录"用微软雅黑小四加紧凑行距，调用时指定类型即可。这样非技术同事也能看懂配置，改起来不用找我，省了不少沟通成本。

6.3 还能往哪走

这个方案还能做不少延展。一个方向是导出前的预览，用 iframe 加载生成的 HTML 让用户先看一眼效果，确认后再下载，能减少很多"导出后才发现不对"的返工。实现上就是把同一份 HTML 塞进 iframe 的srcdoc，成本很低。

另一个方向是加上元数据，比如文档标题、作者、创建时间。这些可以写在 HTML 的meta里，Word 打开后能在文件属性中看到。对于需要归档的场景，这个细节显得很专业。

还有个方向是反向支持，把内容同时导出成 PDF。思路是一样的，只是把 Blob 的类型换掉，然后交给打印或者第三方库处理。如果你的场景同时需要这两种格式，把中间的 HTML 生成环节共用，能省一半代码。我在一个项目里这么做过，两种格式的样式一致性反而比分别实现更好，因为源头是同一份。

再往下走，如果文档结构越来越复杂，复杂到 MHTML 的表达能力撑不住，那就该考虑换成结构化的文档生成方案了，把内容和样式彻底分离。但这是另一个量级的投入，只有在确实需要精细控制每个段落属性、需要处理大量公式和图表时才值得。在绝大多数"把页面导出来"的场景里，MHTML 这条路能撑很久。

最后分享一个我实测出来的小经验：导出前把页面字体统一成系统内置字体，比如微软雅黑、宋体、黑体这三种，能极大降低在别人电脑上打开时的样式偏差。因为文档最终是在用户的机器上被 Word 渲染的，对方机器上装没装你的字体，你控制不了，但你可以选择大家都有。这一点比任何 CSS 技巧都管用，我在踩过好几次"我这边好好的，同事打开全乱了"的坑之后，就把导出场景的字体收敛到了这三种，之后再没收到过类似的反馈。