纯前端 PDF 转 Word 实用指南：格式不乱的技术选型与踩坑实录

纯前端PDF转WordPDF格式转换前端技术选型

于 2026-10-02 03:15:35 修改

·本内容遵循CC 4.0 BY-SA版权协议

前两天有个读者跟我说，他临时需要把一个 30 页的报价单 PDF 转成 Word，产品经理催着要改几个价格数字，结果他用在线转换工具生成之后，表格全乱、图片漂移、页码多出好几页，改了半小时心态就崩了。这其实是纯前端 PDF 转 Word 场景里非常典型的“格式乱”问题。这个提法大家每天都在搜，但真正把原理讲透、把坑踩完的人不多，所以我想把我在实际项目里跑通的经验拆开讲一讲——纯前端到底能做什么、不能做什么、格式为什么会乱、以及什么时候咱们可以用什么招来救。整篇文章面向前端开发者，也面向被 PDF 转 Word 折磨的日常办公用户。

文章核心是一个原则：先别急着写转换代码，先判断你的 PDF 到底适不适合让前端来转。我会把底层原因、技术选型、三条真实跑通的路线、高频问题排查方法全部聊一遍。

1. 先想清楚：这个纯前端方案到底要解决什么问题

1.1 为什么一定要“纯前端”，两个强需求

我接触过大量接“纯前端 PDF 转 Word”需求的人，嘴上说的是技术方案，底子里其实是两个特别现实的需求：第一，敏感文件不能上传到第三方服务器。很多金融、医疗、法务类的 PDF 里全是合同、身份证、内部报告，走在线转换网站等于把机密文件送出去，合规上就过不去。第二，产品形态不允许走后端转换服务，比如某些私有化部署项目、离线环境、或者 CDN 静态托管的前端应用，没有自己的后端可用，只能在浏览器里直接把转换这件事干了。

所以纯前端方案的价值不在于“它是最强的转换引擎”，而在于它为你保住了一条安全底线——文件从头到尾不出浏览器，整个转换过程在你的设备上完成。

1.2 转换的“质量指标”到底该怎么定

做技术的人容易掉进一个误区：以为转换结果必须和 PDF 视觉上一模一样。纯前端的世界里，这个目标基本不可能 100% 达到，所以一开始我建议先和需求方把“质量指标”签好，哪怕只是口头对齐。一般我用四个维度来衡量：

文本完整性：所有字符、段落文字都提取出来了，没有丢失或乱码。
结构可用性：标题层级、段落顺序、表格行列、列表符号基本保留，能正常编辑。
版式还原度：页面尺寸、边距、换页位置、图片位置大致接近原文。
可编辑性：转出来的 Word 不是图片，每个段落、每个单元格都能点进去改字。

记住一个残酷的结论：可编辑性和版式还原度天然是冲突的。你想要 Word 里的文字像原生文档一样随便改、表格结构完全规整，就得接受版式上“差不多”；你想让每一页都和 PDF 长得一模一样，那转出来很可能就是一张大图片，根本没法编辑。这两者只能选一个优先，认清这一点，后面就不会对着结果拍桌子。

1.3 参与选型的眼底方案池

如果你搜“纯前端 PDF 转 Word”，能找到的资料其实非常杂，我先把主流方案梳理一遍，并给一个直接的对比判断：

技术路线	核心库/工具	适合场景	主要限制
PDF.js + docx.js	pdfjs-dist、docx	文本型 PDF、简单排版、对版式要求不高	布局信息大量丢失
PDF 解析 + HTML 中转	pdf.js 配合自身渲染，再用 html-docx-js	有一定排版还原需求，但愿意牺牲小标题	样式丢失、兼容性参差
pdf2json / pdf-lib 等结构抽取	各种解析库	表单类、规律性极强的文档	工作量巨大，只适合特定模板
OCR（tesseract.js）	浏览器端 OCR	扫描件图片型 PDF	慢、错误率不低，后续还需标注坐标
wasm 版转换器（pdf-to-word底层）	自研 C++/Rust 转 WASM	高性能需求，团队有跨端经验	成本高、维护重，不适合快速落地

我这些年在真实项目里的实际感受是：纯前端做不了高精度转换，但能做“够用”的转换。所谓“够用”，就是 文本全在、顺序可读、关键结构能编辑、视觉走样控制在可接受范围内。接下来要做的，是搞清楚到底什么东西在阻挠我们做得更准。

2. 格式乱的深层原因：两种格式在底层就不是一回事

2.1 PDF 是“拍好的照片”，Word 是“可以继续排版的原稿”

很多非技术用户问“为什么转了格式就乱”，其实是没搞懂 PDF 和 Word 的文件本质。我用一个特别直白的比喻：

PDF 就像一张已经洗出来的照片，你看到什么，它存储的就是什么。PDF 底层是一堆“绘制指令”——把文字画在坐标 (x, y) 处，画一条从 A 点到 B 点的线，在某个矩形区域里填充一张图片。它根本不在乎这些字词之间有什么关系，也没有“段落”“章节”“表格”这种概念，只有一个个绝对定位的对象。

Word 恰好相反，它是一份“还没排版定稿的原稿”，底层是文档对象模型（Document Object Model）：有段落、有样式、有表格行、有单元格合并关系、有图文环绕锚点。Word 关心的是内容之间的逻辑关系，而排版是 Word 引擎根据屏幕宽度实时计算出来的“流式布局”。

所以让前端程序去“看懂” PDF 再重建一份 Word，本质上等同于：只看一张照片，就要求还原出照片里所有人的身高体重、前后站位和拍照时用的布光参数。你说这工作难不难？

2.2 格式乱的具体源头：内容位置、顺序、字体、表格四重问题

从实际操作角度来看，我总结出格式乱的四个最常见的“病灶”。

第一是顺序混乱。PDF 不保证文字按阅读顺序排列，尤其是分栏排版的 PDF（比如论文双栏），解析出来文字可能是“左半页第一行，接着右半页第一行，然后再左半页第二行”，直接按抽取顺序写进 Word 就是乱序阅读。我遇到过最夸张的例子是把一个完好的双栏论文解析出了“左右两栏交错朗读”的奇观。

第二是位置信息丢失。纯文本抽取时往往只拿字符内容，不拿坐标，结果所有文字被一股脑拼成密集的段落。这是“格式乱”里最常见也最让用户崩溃的一种——明明原文排版很松、间距很透气，转出来变成一整坨黑字。

第三是字体替换。PDF 里的字体如果是嵌入子集，前端解析出的字体名通常是空壳（或内部名字），映射不到 Word 里的中文字体，最后全变成宋体或者 Calibri。遇到西文字体里的特殊字形（比如公式符号）就直接变成“口口口”。

第四是表格结构塌方。PDF 里没有“表格”语义，只有横线和竖线，以及落在这些线构成的小格子里的一堆文字。要把它们还原成带合并单元格的真正表格，本质上要做“视觉几何分析+行列建模”，纯前端做这件事的难度极高，一没做对，表格就变成乱序文字+分离线条，比什么都难看。

2.3 判断标准：你的 PDF 到底该不该走纯前端

有位老哥问过我一句特别顶用的问题：“什么样的 PDF 值得我用纯前端转 Word？”我现在给一个非常务实的判断清单，凡是命中这几条，纯前端方案的性价比都比较高：

文字型 PDF（可选中、可复制），不是扫描件或纯图片。
版式是单栏或简单两栏，没有复杂的图文叠放，不是杂志级设计。
标题、段落、列表逻辑清晰，本身就来自 Word 或 WPS 导出的电子档 PDF。
表格数量少且行列规整，没有大量合并单元格。
转换目标不是 100% 像素级还原，而是允许人工微调几处排版。

那些多层叠版、艺术字满天飞、大片复杂表格甚至扫描盖章的 PDF，纯前端基本救不回来，此时我更建议直接告诉业务方：要么人手重排，要么走自己架设的离线转换服务，不要硬扛。

3. 实操：三种主流技术路线的完整跑通记录

3.1 路线一：pdf.js 提取文本 + docx.js 重建文档

这是我个人最推荐新手先跑通的一条路，也是“纯文本保底”思路的典型实现。它不做复杂的坐标还原，只追求内容全、顺序顺、可编辑。

用到的核心工具是 pdfjs-dist（Mozilla 出品的 PDF 解析渲染库）和 docx（一个用 JavaScript 生成 .docx 的库）。我直接给一个能跑的最小实现框架：

BASH

npm install pdfjs-dist docx

TYPESCRIPT

import * as pdfjsLib from 'pdfjs-dist';

import {

Document, Packer, Paragraph, TextRun

} from 'docx';

import { saveAs } from 'file-saver';

// 1. 读取 PDF 文件为 ArrayBuffer

const fileBuffer = await file.arrayBuffer();

const pdf = await pdfjsLib.getDocument({ data: fileBuffer }).promise;

// 2. 逐页提取文本，并临时记录段内文字

const pagesText: string[][] = [];

for (let i = 1; i <= pdf.numPages; i++) {

const page = await pdf.getPage(i);

const content = await page.getTextContent();

// 提取每个文本项的字符串

const strings = content.items

.filter((item: any) => item.str && item.str.trim())

.map((item: any) => item.str);

pagesText.push(strings);

}

// 3. 用 docx.js 按页生成 Word 段落

const children = pagesText.flatMap((pageLines, idx) => [

new Paragraph({

children: [new TextRun({ text: `[第 ${idx + 1} 页]`, bold: true })],

}),

...pageLines.map(

(line) => new Paragraph({ children: [new TextRun(line)] })

]);

const doc = new Document({ sections: [{ children }] });

const blob = await Packer.toBlob(doc);

saveAs(blob, 'output.docx');

这段代码能跑，但直接这样用于生产，你大概率会被骂。它把所有文本不分段落、不看坐标全部压成一个接一个的段落，行距还都是默认值，几乎没有格式可言。所以我在实际项目里不会用这么粗暴的版本，我给 pdf.js 的 getTextContent() 加了一层坐标分簇逻辑：把同一行（y 坐标接近）的文本项按 x 坐标从左到右合并成一行，再把相近的行合并成段落。核心逻辑大概是这样：

TYPESCRIPT

function groupTextItems(items: any[]) {

const lineGroups: any[][] = [];

for (const item of items) {

// item.transform[5] 即 y 坐标（PDF 坐标系原点在左下，需要处理）

const y = item.transform[5];

// 找到一条 y 坐标与当前项接近的已有行

const existingLine = lineGroups.find((line) => {

const first = line[0];

return Math.abs(first.transform[5] - y) < 3; // 3 是经验阈值，按需调整

});

if (existingLine) {

existingLine.push(item);

} else {

lineGroups.push([item]);

}

// 每组内按 x 坐标排序，然后 join

return lineGroups

.map((line) =>

line

.sort((a, b) => a.transform[4] - b.transform[4])

.map((item) => item.str)

.join('')

)

.filter((line) => line.trim());

}

我实测下来，这种“按坐标聚类+行内排序”的方式能解决掉至少 60% 的文本乱序问题。比如一份 20 页的商业计划书，直接提取文本的顺序是乱的，加上分簇之后，每行文字正确串起来了，页与页之间的连续性变好很多。它的问题在于，遇到双栏排版，左侧第一栏中间如果有个图片，右侧第二栏的文本就可能被错误并入左侧的一行，阈值需要反复调，3px 只是起点。我不建议把它继续调到很小的数值，因为那样又会把同一个段落切成十几段。

3.2 路线二：pdf2json 抽取结构 + 模板映射

有些有固定模板的 PDF，比如企业统一格式的报价单、数据报表、成绩单，它们每一页都是“同样的骨架，不同的数据”，这时候用通用文本提取就太亏了。更高效的方法是抽取结构 + 模板映射。

我推荐在 Node.js 侧用 pdf2json 来做解析（它也可以在浏览器侧跑），它能输出每个文本块的位置、字体、字号、颜色信息。我的做法是：

先用一份“样板 PDF”跑出解析结果，把页面上的关键字段的坐标框记下来。
写一份 JSON 映射表，比如“title 在坐标 (50, 50)，value 在坐标 (120, 50)”。
对每一份新 PDF，重复执行解析，按坐标匹配映射表里的字段，再拼接成 Word 表格和段落。

这个方案的优点是非常可预测，格式不会乱，因为它根本不做通用排版的猜测，而是在“已知世界”里填空。缺点也显而易见：换一个模板就是一次新开发。我个人通常建议在项目里只针对高频模板做这种定制，不要试图做成“万能模板适配器”，否则维护成本远超收益。

3.3 路线三：pdfjs-dist 定位文字位置 + 直接操作 docx 底层 XML

如果你对版式还原的要求比“纯文本保底”更高，又想避开网页渲染到 Word 带来的各种兼容问题，有一个“扎实但繁琐”的路线：用 pdf.js 把每个文本块的位置和字体信息全部取出来，再在生成 .docx 时直接用文本定位参数。

docx 库里其实有 TextRun 的 position 属性和段落缩进、制表位等参数，你可以把 PDF 里的坐标相对转换好，再用制表位把文字推到指定位置。但坐标换算复杂度非常高：PDF 坐标原点是左下角、y 轴向上；Word 的布局逻辑是流式+绝对定位混用，页面边距、字号行距都在影响最终视觉位置。我试过把 PDF 里 (x, y) 直接映射到 Word 的段落缩进，预览效果很惊艳，但放大缩小之后错位就出来了，因为 Word 的宽度是响应式的，而你定位时假设是固定宽度。

如果你坚持这条路，我建议只对不换行的标题、图注、页眉页脚这类独立元素做绝对定位，文本正文还是老老实实用流式段落，这样视觉还原度能上一个台阶，又不会满盘皆输。

3.4 三条路线的对比结论与实战建议

折腾完这三条路线之后，我的个人偏好其实非常明确：

日常办公文档、合同、报告：路线一（坐标分簇版）性价比最高，花两三个小时写一个通用转换器，覆盖 80% 的文本型 PDF 场景。
固定模板报表/单据：路线二最可靠，输出结果干净得像原生文档，但需要额外做模板开发。
对版面要求高的宣传册、说明书：路线三只做“局部绝对定位+正文流式”，但你要有心理预期，结果还需要人工微调。

还有一个重要补充：转换后最好生成一个 Markdown 格式的中间结果。我实际操作时通常会先把抽取的文本+结构输出成 Markdown，人工或脚本检查一遍，再由 Markdown 生成 Word。这样一方面方便定位是“解析阶段”出了问题还是“生成阶段”出了问题，另一方面也能复用 markdown 转 word 的成熟工具链（Pandoc、md-to-docx 等）。别把解析和生成两大块混在一起调试，否则出了问题你根本不知道是哪个环节把格式搞乱的。

4. 实战避坑：频率最高的 5 类问题与排查方法

4.1 图片大量丢失或位置漂移

“转出来图片全没了”是投诉率最高的一个问题。原因在于很多纯文本提取的 PDF 转 Word 方案，压根就没去做图片提取这一步。如果你需要保图片，不能只用 getTextContent()，还得用 pdf.js 的 page.objs 和 operator list 把图片资源解析出来。

我的基本套路是：通过 page.getOperatorList() 找到 paintXObject 指令，拿到 Object 编号后，用 page.commonObjs 或 page.objs 获取图片数据，再转成 base64 或 Blob，最后通过 docx 库的 ImageRun 插入 Word。

TYPESCRIPT

const opList = await page.getOperatorList();

for (let j = 0; j < opList.fnArray.length; j++) {

if (opList.fnArray[j] === pdfjsLib.OPS.paintXObject) {

const xObjectKey = opList.argsArray[j][0];

const imgObj = await page.objs.get(xObjectKey);

// imgObj 通常有 `data` 属性（Uint8Array），转成 Blob 使用

}

有一个细节容易被忽略：很多 PDF 里的图片是“底图”，也就是水印、背景纹理、装饰性色块，它们被提取出来之后塞进 Word 会让文件变得巨丑无比。我处理的原则是：宽度小于页面宽度 60%、且被其他文本压住的图片，默认当作装饰丢弃。判断文本是否“压住”图片，可以用图片 bbox 和文本项 transform 做重叠检测。这个逻辑写起来麻烦，但能省掉大量清理工作。

4.2 表格合并单元格塌掉

表格是纯前端转换的重灾区，这里的核心难点是：PDF 里的表格没有结构定义，只有线条和文字。所以想要还原表格，必须先做“线检测”。

优化后的操作路径是：从渲染后的 PDF 页面上下文中，找到所有横线和竖线的坐标（可以用 pdf.js 拿到 path 绘制指令，也可以将页面渲染到 canvas 之后做像素级线条检测），再用这些线的交点划分出单元格区域，最后把落在同一单元格里的文本合并到对应的 <w:tc> 里。

但真正生产时，我通常不追求自动重建所有表格，而是执行一个折中方案：把表格内容识别为段落列表，并保留单元格内文本的顺序。这会让最终 Word 看起来像“带数字的分段文字”，但至少内容没丢、顺序没乱。如果业务上必须在 Word 里得到一个规范表格，我会建议用模板映射或人工辅助调整，而不是硬扛一个万能表格识别。

4.3 字体全变默认宋体/Calibri

字体丢失几乎是必然的，但有些技巧可以把伤害降到最低。

我先说原因：PDF 里嵌入的字体子集，表面上的字体名（FontName）常常是子集前缀 + 内部标识，比如 ABCDEF+SimSun，前端解析时它的真实样貌已经“锁在”子集里了，Word 里没有这个子集，只能按默认字体替换。纯前端技术很难把 PDF 里嵌入的字体提取成一个完整的字体文件再嵌入到 Word，工作量和兼容性风险都很大。

实操上我建议这样做：预置一个字体映射表，把常见的 PDF 内部字体名映射到 Word 系统字体名，比如 SimSun→宋体、SimHei→黑体、ArialMT→Arial。再用 TextRun 的 font 属性显式设置到每个段落上。同时要注意，PDF 里同一份文本的字体信息会存在 TextItem 上，必须按字体分组生成 TextRun，否则 Word 里一整个段落只能选一种字体。

一个要提前确认的事：生成的 Word 在 Windows 上打开和 Mac 上打开，字体渲染可能不同。前端转换结果本身就是“尽量贴近”，要跟业务方对齐这个预期。

4.4 转换后 Word 文件体积爆炸

这是大家容易忽略的一个坑。原因很直接：PDF 里的图片是 JPEG 压缩的，但提取出来之后如果不处理，可能变成无损 PNG，或者直接以巨大的 base64 进入 docx，体积直接翻三五倍。

我处理图片时会加一个压缩步骤：如果图片分辨率超过页面显示尺寸的 2 倍，就先用 canvas 缩放再导出为 JPEG（质量 0.8）。给一个常规的参考：

TEXT

1. 如果图片宽度 > 1200px，等比缩放到 1024px；

2. 导出为 JPEG，quality 0.8；

3. 如果原始格式 PNG 且含透明通道，先填充白色背景再转 JPEG；

这样处理后，一个原来 20 页带大量扫描图的 PDF，生成的 Word 基本不会超过 15MB，勉强可控。如果你不做压缩，同样是 20 页扫描图，可能生成 60MB 的巨无霸，打开都卡。

4.5 多页 PDF 错乱：顺序颠倒、内容重复

顺序问题在前面原理部分已经提过，但多页之间还有一个更常见的错乱来源：把同一个文本对象提取了两次。比如 pdf.js 对某些 PDF 会同时返回透明渲染层和普通渲染层，如果不去重，就是复制了一遍全部文字。

排查思路是：先抽出一个 PDF 页面的原始文本项列表，检查 str 是否大量重复，或者相邻 y 坐标重复出现两套数据。去重时要注意不能只按字符串去重，因为不同位置完全可能出现相同的两个词（比如每页页眉的公司名），必须同时判断 transform 坐标是否重合或接近。

多页错乱的另一个来源是页面的读取顺序。我强烈建议在解析时记录当前 pageNumber，在生成 Word 时把它作为注释性标题插入。虽然用户最后会删掉这些标题，但至少转换结果能快速定位是哪一页出了乱子。

5. 我的脚手架：一个能落地的组合策略

5.1 按内容类型分级：什么 PDF 用哪种策略

经过多个项目的验证，我现在处理纯前端 PDF 转 Word 需求时，会先按内容类型分三档策略：

内容类型	推荐策略	预期效果
纯文字报告、合同、标书	文本提取 + 坐标分簇 + 段落映射	文字顺序、段落结构基本正常，少量排版需微调
带表格的报表、财务单据	模板映射或表格线检测 + 手动修正	数据完整，表格结构接近原文
扫描件、图片型 PDF	tesseract.js OCR + 坐标标注，或者直接建议不做	文本内容可搜索，但版式无法完全还原

这条分级的好处是让团队知道“做到什么程度算验收通过”，而不是拿着百分百完美转换的幻想反复改需求。

5.2 质量验收清单：别等交付才发现问题

我每次交付纯前端转换功能前，都会跑一遍清单：

[ ] 全文文字是否全部提取，随机抽三页人工比对；
[ ] 页眉页脚是否被当作正文误插入内容（很多 PDF 的页眉页脚在文字流里特别碍事）；
[ ] 常见标点符号、引号、括号是否出现乱码（中英文引号经常互转出错）；
[ ] 段落之间是否有异常的空行或缺失；
[ ] 表格数据是否按原行列顺序保留；
[ ] 图片关键数量是否一致，文案中引用的图片不能丢；
[ ] 输出的文件能否正常打开，体积是否在可接受范围。

这个清单我用过很多次，每次都能揪出至少一两个自己没意识到的低级问题。

5.3 原创实用技巧：做一个“预览-诊断-导出”的前端小工具

我最后想分享一个特别有用的小经验：不要在纯前端转换流程里一步到位直接导出 Word，而是拆成三个动作——预览、诊断、导出。

预览阶段，把抽取出来的文本按页展示在网页上，用户看得到内容是否完整、顺序是否正常；诊断阶段，自动统计“疑似乱码字符数”“疑似重复段落数”“图片数量偏差”，把警告显示出来；导出阶段，生成最终 Word。这个工具上线后，我接到“转换结果乱”的反馈减少了非常多，因为在导出之前，用户就能第一时间自己发现“文本全乱了”，不用等 Word 下载下来再跳脚。

技术上实现也不难，你只需要在解析类逻辑后面加一个 UI 层，把中间结果以可读的形式渲染出来。这个功能对内部工具的价值非常明显，强烈建议直接抄作业。

5.4 最后说几个绕过“纯前端”的心得

在某些要求比较高的场景里，纯前端确实做不到理想效果，这些情况下不要硬扛，该认怂就认怂。我实际处理过的几个替代方向是：

如果用户只是偶尔手动转几份文件，引导他们用浏览器自带打印功能里的“另存为 Word”或 WPS 内置转换，简单高效。
如果你能拿到 PDF 的生成来源（比如 LaTeX、Word 原稿、Markdown），那直接源代码转 Word，比从 PDF 里逆向重建一万倍轻松。优先找原稿，别从成品 PDF 反推。
对于高精度、大批量场景，建议在后端布置开源的文档转换服务，前端只上传和下载结果，这样既保证外观还原度，又不用自己造核心引擎。

在一次真实项目里，客户最初坚持“浏览器里一键转”，我给他们看了效果和限制，最终压缩到“前端解析+后端转换服务”的混合方案，效果立竿见影。技术方案不能感情用事，要按文件特征和交付目标来选。

我在实际操作中反复体会到，纯前端 PDF 转 Word 本质上是一个“内容保底、版式尽力”的工程，不是花哨的黑科技。先把 PDF 分类判断清楚了，再选择对应的策略，然后老老实实解决顺序、图表、字体和体积这几个关键问题，结果一定比盲目拷一段代码然后抱怨“格式全乱了”靠谱得多。这个方向后续还可以扩展到 PDF 转 Markdown、批量文件预处理、甚至浏览器内 OCR 与版面分析的组合场景，骨架已经有了，项目多了自然就能沉淀出更顺手的转化工具链。