在浏览器端直接生成 PDF 文档已成为现代 Web 应用的标准需求：从发票生成、报告导出到电子书制作，客户端 PDF 生成的场景日益丰富。然而，一个看似简单的需求 —— 让生成的 PDF 支持文本选择和复制 —— 却隐藏着复杂的技术实现细节。本文将深入剖析三条主流技术路径的工程权衡，为开发者提供可落地的技术选型指南。
文本选择的技术本质
PDF 文件格式本身并不存在所谓的 “文本层” 概念，所有内容在 PDF 内部均以绘图指令形式存储。文本以字符编码和位置坐标的形式描述，要实现可选择文本，需要在生成阶段正确写入文本映射信息。这一过程涉及三个核心环节：字体子集化处理、字符坐标映射、以及 PDF 内容流中的文本对象正确声明。
传统服务端 PDF 生成工具（如 PDFKit、WeasyPrint）天然支持文本选择，因为它们基于完整的字体文件和成熟的 PDF 规范实现。客户端环境面临的核心挑战在于：如何在资源受限的浏览器环境中完成这些计算密集型操作，同时保持输出的可移植性。
路径一：PDF.js 渲染层方案
PDF.js 是 Mozilla 开发的 PDF 渲染引擎，其设计初衷是提供高质量的 PDF 查看能力，而非生成能力。然而，在某些场景下，可以利用 PDF.js 的文本提取能力配合其他生成工具实现文本选择功能。
PDF.js 的核心优势在于其文本层提取算法。它能够解析现有 PDF 的字符位置信息，并生成可交互的文本选择覆盖层。对于需要展示用户已上传 PDF 并支持文本选择的场景，PDF.js 是成熟的选择。但若目标是根据动态内容生成新 PDF 并保留文本选择能力，PDF.js 的作用则相对有限。
工程实践中，PDF.js 更适合作为查看层组件。开发者可以在服务端或通过其他库生成基础 PDF，然后使用 PDF.js 渲染并利用其内置的文本选择功能。这种方案的优势在于用户体验一致，文本选择行为与原生 PDF 阅读器相似。关键配置参数包括：文本渲染模式（textLayerMode）、高亮颜色、以及选择事件的回调处理。
路径二：PDFLib 生成层方案
PDFLib（如 pdf-lib）是专为客户端 PDF 生成设计的 JavaScript 库。它允许开发者在浏览器中创建全新的 PDF 文档，或修改现有 PDF 内容。与 PDF.js 不同，PDFLib 的核心能力是生成而非渲染。
实现文本选择的关键在于正确使用 PDFLib 的文本 API。开发者需要指定字体、字体大小、文本内容以及精确的坐标位置。PDFLib 支持嵌入自定义字体，这对于确保跨环境一致性至关重要。值得注意的是，要实现真正的文本选择，字体必须正确嵌入且使用 Unicode 编码。
以下是在 PDFLib 中实现文本选择的核心参数：字体嵌入使用 embedFont 方法，文本绘制使用 drawText 并指定坐标系统，字符间距通过 setCharacterSpacing 调整。字体子集化是另一个关键考虑 —— 完整嵌入中文字体可能导致文件体积过大，而子集化仅包含实际使用的字符，是平衡文件大小与文本选择能力的最佳实践。
PDFLib 的优势在于完全可控的生成过程，开发者能够精确控制每个文本元素的位置和属性。缺点则是需要手动处理分页、样式计算等逻辑，实现成本相对较高。
路径三：原生 Canvas 渲染路径
第三条技术路径是先将内容渲染到 Canvas，再将 Canvas 图像嵌入 PDF。这种方案的文本选择能力完全取决于生成策略：若仅嵌入图像，则文本选择功能丧失；若配合隐藏文本层技术，则可在保持视觉输出的同时保留选择能力。
原生 Canvas 路径的实现流程如下：使用 Canvas API 或 HTML2Canvas 等库将 DOM 内容渲染为图像，然后将图像作为 XObject 嵌入 PDF。若需要文本选择，需额外使用 PDFLib 或类似工具在同一位置写入不可见的文本层。这种 “双层” 方案是 Adobe Acrobat 生成可搜索 PDF 的经典技术。
该方案的优势在于：能够完美还原复杂 CSS 样式，包括渐变、阴影、混合模式等视觉特效。对于样式高度定制化的场景（如营销材料、设计稿导出），Canvas 路径是可靠的选择。工程参数包括：Canvas 分辨率系数（建议 2x 以保证打印质量）、图像压缩算法选择（JPEG 或 PNG）、以及隐藏文本层的坐标同步机制。
技术选型决策框架
基于上述分析，开发者可依据以下决策树进行技术选型。若核心需求是在浏览器中查看 PDF 并支持文本选择，直接采用 PDF.js 即可。若需求是生成新 PDF 并保留文本选择能力，需评估内容复杂度：结构化数据驱动的文档生成（如报表、发票）推荐 PDFLib 配合完整字体嵌入；样式高度定制的内容（如设计稿、营销页）推荐 Canvas 图像加隐藏文本层的双层方案。
文件体积是需要重点关注的指标。完整嵌入中文字体可能导致单文件超过 10MB，而通过字体子集化可将其控制在数百 KB 以内。子集化工具如 fontkit（Node 端）或 subfont（构建时）可帮助实现这一优化。
可访问性是另一个关键考量。支持文本选择的 PDF 必须正确声明语言属性（Lang 字段）、使用结构化标签（Tagged PDF），并确保足够的颜色对比度。这些属性不仅提升用户体验，也是满足 WCAG 合规要求的基础。
工程实践关键参数
无论选择哪种路径，以下参数配置值得开发者关注。字体加载策略上，生产环境建议使用预加载的 WOFF2 格式字体，并通过 FontFace API 注入。坐标系统方面，PDF 采用 72 DPI 的坐标系，原生 Canvas 多采用 96 DPI，需要进行比例换算。颜色空间处理上，为确保跨浏览器一致性，建议将颜色值转换为 CMYK 或使用 sRGB 色彩空间声明。
错误处理机制同样重要。浏览器端 PDF 生成可能因内存限制（大型文档）、字体加载失败（网络问题）或 Canvas 渲染超时而失败。建议实现降级策略：文本选择失败时至少保证可读性，图像生成失败时回退到纯文本模式。
结论
客户端 PDF 文本选择并非单一库能够完整解决的问题，而是需要根据具体场景组合使用生成库与渲染层。PDFLib 提供了最可控的生成能力，PDF.js 是查看层的成熟选择，而原生 Canvas 路径则在样式保真度方面具有独特优势。理解这三条路径的技术本质和权衡因素，是做出正确架构决策的前提。
资料来源：本文技术细节参考 SDocs 团队关于客户端 PDF 生成的实践分享，以及 PDF.js、PDFLib 官方文档。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。