不过，

背景

最近做了一个PDF工具站。主要需求是：所有操作都在浏览器完成，文件不离开使用者设备。

这个需求看似简单，但实现起来有不少坑。其实，这篇文章记录技术选型、主要实现和踩坑过程，给有类似需求的同学参考。

使用者的真实痛点与产品动机

User interviews反复出现的抱怨。直接决定了纯前端方案的必要性：

• 隐私焦虑，不敢上传敏感文件。  合同、简历、证件照一旦传到第三方服务器。 就有泄露风险，公司和个人都极度抗拒“先上传再处理”。这是最致命的使用者拒绝理由。
• 网络依赖与等待成本高。 大文件上传慢，处理完还要下载一次移动网络下经常超时断线。使用者体验极差，“点了半小时还在转圈”。
• 费用与并发不可控。 PDF处理是CPU密集型操作。后端并发高时服务器扛不住运维成本直线上升，使用者却要承担价格或排队。
• "用完就崩"的糟糕体验。 200MB扫描件直接卡死浏览器、中文字体变成方块乱码、下好文件名在Safari里显示乱码。这些细节让使用者觉得产品不可靠，随时弃用。说起来，
• "我想临时处理一下却不想装软件"。 临时合并几份资料的需求频发，使用者只想要打开网页拖拽即用。而不是安装Adobe Acrobat这类重型软件。

技术选型

为什么不用后端？对比带来的使用者痛苦更直观

传统流程这方面，使用者上传 → 服务器处理 → 返回结果。看似省事，实则放大了上面的每个痛点：隐私风险被放大、大文件网络往返耗时长、大并发下成本失控。老实说，纯前端把“信任”和“速度”交还给使用者，也是我们坚守的方向。说起来，

• 隐私风险             敏感文档上云。使用者不敢用，甚至违反合规要求；这也是咨询类客户流失的首因。
• 网络依赖      大文件上传慢。下行又要等待，使用者感觉“在帮你干活而不是你在帮我”。流量费和时间成本都是隐形痛苦。
• 服务器成本   PDF解压渲染极吃CPU。高峰期一堆人同时处理会打爆实例，最终只能限流或涨价转嫁给使用者，形成恶性循环。

主要库选择

li>pdf-lib——负责"写" PDF 合并/拆分/添加水印 等 约500KB API友好 li>pdfjs-dist——负责"读" PDF 解析预览提取页面 约0.5MB Mozilla出品解析能力强 li>file-saver——浏览器端下载 约5KB Safari兼容好 / ul> p>配合逻辑为& nbsp; :pdf-lib 处理结构写入,pdfjs-dist 提供预览和图片提取。pako 版本统一后避免冲突& nbsp;/ p>

主要功能实现

PDF 合并—解决"我有一堆零散文档要拼成一份"的日常烦恼

 import { PDFDocument } from 'pdf-lib'
async function mergePDFs {
const mergedDoc = await PDFDocument.create
for {
const bytes = await file.arrayBuffer
const pdf = await PDFDocument.load
const pages = await mergedDoc.copyPages)
pages.forEach)
}
return mergedDoc.save
}

& nbsp;:关键要点 & nbsp;:copyPages 而不是直接addPage，页面必须来自同一文档实例 & nbsp;:file.arrayBuffer 是原生API 无需读写磁盘 & nbsp;:大批量合并时建议显示进度条，避免使用者以为卡死而刷新丢进度 & nbsp:/ strong>

PDF拆分—精准提取页码。不想手动一张张另存

 import { PDFDocument } from 'pdf-lib'
function parsePageRanges{
const pages = new Set
input.split.forEach(part=>{
const =part.trim.split.map
if{ pages.add } else {
for;i++) pages.add
}
})
return Array.from.sort=>a-b)
}
async function splitPDF{
const bytes=await file.arrayBuffer
const pdf=await PDFDocument.load
const pageIndices=parsePageRanges)
const newDoc=await PDFDocument.create
const pages=await newDoc.copyPages
pages.forEach)
return
}

& nbsp;其实，:页码转换 使用者习惯从1开始。pdf-lib 从0开始 & nbsp;怎么说呢，:一次性连续范围提取减少内存操作 & nbsp:/ strong>

PDF压缩—解决"我发邮件超大小了怎么办"的焦虑

 import { PDFDocument } from 'pdf-lib'
async function compressPDF{
const bytes=await file.arrayBuffer
const pdf=await PDFDocument.load
// 策略1 清理元数据注释 未使用对象 流调整 objectStreams true
// 策略二配合pdfjs-dist降低图片质量重编码 对扫描件效果有限但对普通文档有效
return pdf.save
}

& nbsp;:实际效果预估 & nbsp;:轻度清理元数据+对象流调整 通常减少10%~25% & nbsp;:中度降图 通常减少30%~50%但可能影响阅读清晰度 & nbsp;:重度降分辨率 可能再减更多 但扫描件极限有限 不能期望像Ghostscript那样深度压缩 & nbsp:/ strong>

踩坑记录—把使用者的崩溃场景提前兜住

坑1 大文件内存溢出 使用者看到白屏崩溃

问题描述:.200MB扫描件直接让标签页崩溃，使用者认为是产品bug并给出差评。根因:.整个文档被加载到内存 解压后占用数倍。解决:.100MB软限制+友好提示建议桌面软件 分块逐页读取 进度提示避免假死。

const MAX_SIZE =100*1024*1024
if{ throw new Error})建议先压缩`) }

坑二 中文字体显示方块 合并后看不了

问题描述:.中文变成豆腐块 让业务合同无法交付。根因:.创建新页面再写入文本会丢失字体映射。解决:.仅做合并拆分时一律copyPages保留原始字体 若需编辑文本必须显式嵌入中文字体包 体积增加约10MB。

坑三 库版本冲突导致解析报错

原因:.pdfjs-dist 与pdf-lib 同时依赖不同版本 pako。解决:Vite 配置别名统一版本 并optimizeDeps 预编译两库避免运行时重复加载。

坑四 Safari 下载文件名乱码

现象:.URL.createObjectURL 在Safari中文文件名乱码 使用者找不到文件。解决:.统一使用file-saver 的saveAs 跨网站稳定。

性能调整

Web Worker 处理大文件不阻塞主线程

把merge/split逻辑放到Worker 后台运行 主线程只负责UI反馈，避免页面卡顿白屏。

按需延迟加载pdfjs-dist

预览才动态import 节省首屏体积约0.5MB，提高冷启动速度。

最终效果与边界说明

目前上线功能覆盖日常办公场景：

li>: 合并PDF ->pidf-lib copyPages - 文件上限<:100MB - 用户价值 一键拼合同报销单 / li> li>: 拆分PDF ->pidf-lib 指定页抽取 - 上限<:100MB - 用户价值 只发需要的章节保护信息 / li> li>: 压缩PDF ->pidf-lib save调整+可选降图 - 上限<:50MB - 用户价值 能顺利邮件发送微信传输 / li> li>: 转图片/图片转PDF 用pdfjs渲染canvas或嵌入图片 上限<:50MB / li> / ul>

再看在线体验，sotool.top

纯前端的主要优势是隐私可控零上传 代价是受限于浏览器内存CPU。怎么说呢，适合✅ 日常办公小中文档、私密敏感资料、无安装临时使用。不适合❌ 超大扫描件几百M上千页 专业印刷级色彩管理 需要批量定时自动化任务。如果你也在做类似项目欢迎交流具体踩坑经验，一起把这些隐形的使用者痛苦真正抹掉。