第十七篇：PDF 压缩合并拆分工具，围绕上传材料的真实痛点

记录 PDF 压缩合并拆分工具的设计与发布：为什么选择浏览器本地处理，如何覆盖 PDF压缩、PDF合并、PDF拆分、PDF文件太大和 PDF压缩到10M以内这些真实搜索需求。

第十七篇：PDF 压缩合并拆分工具，围绕上传材料的真实痛点

这次做的是 yuan-pdf-toolkit，中文名叫 PDF 压缩合并拆分工具。它不是一个为了显得“功能很多”的 PDF 工具箱，而是围绕一类很具体的场景：提交材料、发邮件、上传系统时，PDF 文件太大；或者多个 PDF 需要合并成一个；又或者只需要从一个文件里提取某几页。

这些需求背后有几个关键词很清晰：PDF压缩、PDF合并、PDF拆分、PDF文件太大、PDF压缩到10M以内。但我更关心的是关键词后面的焦虑：文件可能是身份证、合同、报名材料、盖章扫描件，用户不一定愿意上传到陌生网站，也不一定想安装大型软件或注册账号。

这次的产品判断

我把工具定位成“浏览器本地处理的 PDF 常用操作台”。

首版做了这些功能：

• PDF 压缩：提供结构优化和扫描件压缩两种模式。
• PDF 合并：多个文件按顺序合成一个 PDF。
• PDF 拆分：输入页码范围提取，或逐页拆分并打包成 ZIP。
• 删除页面：删掉空白页、错页或不需要提交的页面。
• 重新排序：按新的页码顺序生成整理后的 PDF。

这里我没有把“压缩”写成一个过度承诺。PDF 的复杂度很高，如果原文件已经压过，或者主要是图片扫描件，单纯重写结构不一定能明显变小。所以界面和文档里把压缩分成两条路：

• 结构优化：尽量保留文字、矢量内容，速度快，但压缩幅度有限。
• 扫描件压缩：把页面渲染成图片后重新生成 PDF，更适合把 PDF 压缩到 10M 以内，但可能失去可复制文字、书签或表单字段。

这个边界必须讲清楚。用户拿它去上传报名系统或政务系统时，最怕的是工具把文件弄坏了还不说明代价。

技术实现

项目仍然沿用 Yuan Tools 的标准结构：

D:\dev\yuan-tools\yuan-pdf-toolkit

核心依赖是：

• pdf-lib：合并、拆分、删除页面、重新排序和结构优化。
• pdfjs-dist：在浏览器本地渲染 PDF 页面，用于扫描件压缩。
• jszip：逐页拆分时，把多个单页 PDF 打包为一个 ZIP。
• Svelte + Vite：做 Web 版界面。
• Tauri v2：生成 Windows 桌面版 EXE。

整体逻辑分成两层：

src/lib/core/tool.ts   通用解析、页码范围、文件名、大小格式化
src/lib/core/pdf.ts    PDF 读取、合并、拆分、压缩和导出

我还加了单元测试，覆盖页码范围解析、重新排序校验、目标大小解析、文件名清理和 SEO 关键词常量。PDF 实际渲染部分主要通过构建和发布验证来兜底。

发布结果

这次发布到独立仓库：

• GitHub 仓库：yuan0727/yuan-pdf-toolkit
• GitHub Release：v0.1.0
• Windows EXE：yuan-pdf-toolkit-win-v0.1.0.exe
• Web 静态包：yuan-pdf-toolkit-web-v0.1.0.zip
• 使用说明：yuan-pdf-toolkit-guide-v0.1.0.md

主站也同步了两个入口：

• 工具介绍页：/tools/pdf-toolkit/
• 在线使用页：/apps/pdf-toolkit/

这次的一个小插曲

发布源码时，本机 git push 到 GitHub 的 HTTPS 连接一直被重置。但 GitHub API 可以访问，所以我最后用 GitHub Git Database API 创建了远程 main 分支提交，用 API 创建了 v0.1.0 标签，再用 GitHub Release 上传资产。

这不是最常规的路径，但它也提醒我：如果要把这套小工具流水线长期跑下去，发布链路不能只依赖某一个命令顺手成功。只要产物、提交、标签、Release 和主站同步都能被验证，流程就仍然可控。

下一步

PDF 工具后续可以继续加两类能力：

• 批量压缩队列：一次处理多个 PDF，更适合材料整理。
• 更细的压缩参数：分辨率、图片质量、是否保留文本层等。

但首版先把最真实的动作做稳：文件太大就压缩，材料分散就合并，只要几页就拆分，不该提交的页就删除。对一个小工具来说，这比堆一堆看起来很专业但用户不敢点的设置更重要。