PDF.js 解析大文件时页面卡死怎么办
直接调用 pdfjsLib.getDocument() 去加载一个几十兆的报表PDF，浏览器卡住几秒甚至直接崩溃——这场景是不是很熟悉？问题往往不在于代码写错了，而是PDF.js的默认行为在作祟：它会尝试把整个文件一口气解码进内存，然后再进行渲染。这种全量解析的模式，对大型文件来说简直是性能杀手。
- 首要的优化策略，是启用流式分片加载。在初始化文档时，加上
disableAutoFetch: true和rangeChunkSize: 65536这两个参数。这样一来，PDF.js就会按需拉取数据块，而不是试图吞下整个文件。 - 另一个关键点是渲染时机。别在主线程里一调用
getPage()就立刻执行render()。更聪明的做法是，先用getViewport()获取页面尺寸信息，然后把实际的绘制任务丢给Worker线程，或者利用requestIdleCallback在浏览器空闲时处理。 - 如果你的目标仅仅是提取文字内容（比如做数据导入），那么请直接使用
getTextContent()方法。比起渲染整页，它的速度要快上一个数量级。别忘了，还可以加上normalizeWhitespace: true参数，它能帮你自动清理掉恼人的换行和多余空格。
后端拆分PDF再传给前端是否更稳
这个思路是对的，但具体怎么“拆”，里面大有学问。如果简单地用 pdfseparate 或 pdftk 这类工具按页切割，一个100页的PDF会瞬间变成100个独立文件，导致前端发起大量请求，整体加载进度反而可能被拖慢。更优的方案是，在Node.js服务端使用 pdf-lib 这样的库，先将整个PDF合并加载，再按照逻辑单元（比如每5页，或者每个完整章节）进行分块提取。
- 在服务端，通过
pdf-lib的PDFDocument.load()加载原始文件，然后利用copyPages()方法精确提取指定的页面范围。这样做可以避免对不需要的页面进行全量解析。 - 传输时，不要直接返回原始二进制流。可以将其转换为
base64字符串，或者生成blob URL再传给前端。同时，务必确保fetch的响应头里包含Content-Range字段，否则前端无法准确判断当前分块是否已加载完成。 - 需要特别留意的是，
pdf-lib对加密PDF的支持比较有限。如果遇到Invalid password或Missing endstream这类报错，可以先用qpdf --decrypt命令对源文件进行预处理和解密。
前端导入时用户无感知，怎么加进度反馈
PDF.js 本身并没有暴露底层的精细加载进度。单纯依赖它的 onProgress 回调，只能拿到一个比较粗粒度的百分比（比如“已加载32%”）。这个数值变化并不线性，对于那些包含大量图片的报表PDF，前10%的加载可能就消耗了80%的时间，用户体验会很糟糕。
- 一个有效的办法是将进度拆分成两段来估算：网络加载阶段，可以利用
fetch返回的ReadableStream，配合tee()方法实时计算已读取的字节数；PDF解析阶段，则监听pdfjsLib.getDocument()的onProgress事件。将这两个阶段的进度进行加权平均，得到的反馈会准确得多。 - 更新进度条时，要避免性能陷阱。不要用
document.getElementById('progress').value = ...这种简单粗暴的方式频繁更新DOM，重绘太密集会卡顿。改用requestAnimationFrame进行节流，确保每16毫秒最多只更新一次UI。 - 还有一点常被忽略：如果用户在导入过程中切换到了其他浏览器标签页，记得监听
visibilitychange事件。一旦触发，就暂停解析逻辑。否则，后台线程仍在拼命工作，不仅白白消耗CPU资源，还可能影响当前活跃页面的性能。
为什么分批导入后数据对不上
这个问题在处理包含跨页表格或复杂页眉页脚的报表PDF时尤为常见。如果只是机械地按页码切割，很可能导致第5页末尾的表格行被硬生生截断，而第6页开头又没有补上必要的表头信息。后端解析器拿到这种“残缺”的数据，出错也就在所难免了。毕竟，PDF本质上只是一系列绝对坐标下的绘制指令，它自己可没有“逻辑行”或“表格结构”这种概念。
- 在前端决定如何分批之前，最好先通过
pdfjsLib.getDocument().then(doc => doc.numPages)获取总页数。然后，结合具体的业务规则来确定批次边界。例如，可以设定“每批必须包含至少一个完整表格”，这就需要人工或通过算法预先标记出表格的起止页码。 - 后端进行解析时，也不能完全相信
getTextContent()返回的items顺序。更可靠的方法是，先根据文本项的y坐标进行聚类（同一行），再在同一行内按x坐标排序。对于这种复杂的版面分析，pdfplumber库通常比PyPDF2表现得更出色。 - 从源头上预防：如果在生成PDF时使用了CSS属性
page-break-inside: a void来避免表格内分页，但某些浏览器转换工具可能不识别。这时，需要确保同时加入了打印媒体查询：@media print { table { break-inside: a void } }，才能真正生效。
说到底，技术上的切分与加载并非真正的难点。真正的挑战在于，如何应对报表PDF中那些没有明确声明、却又实际存在的语义结构——比如页码、小节标题、合计行。这些信息往往不直接写在文本流里，却决定了数据最终该如何对齐。解决这个问题，需要综合运用坐标分析、字体大小比对以及前后空白推断等多种手段，目前还很难做到完全自动化。
