企业官网建设流程全解析

1. 从需求出发：为什么要在浏览器里做HTML转PDF？

如果你是一名前端开发者，或者需要处理大量文档的运营、产品经理，这个场景你一定不陌生：用户在你的Web应用里填写了一份精美的表单、浏览了一个数据报表，或者查看了一份合同草稿，然后点击了一个“下载为PDF”的按钮。几秒钟后，一份排版规整、内容完整的PDF文件就保存到了本地。这个看似简单的功能背后，其实藏着不少技术选型和实践细节。

为什么这个需求如此普遍？核心原因在于PDF的“确定性”。HTML在浏览器里的渲染效果，会受到用户设备、浏览器版本、字体缺失、网络资源加载等多种因素的影响。同一份HTML，在你的4K显示器上可能完美无缺，在用户的旧笔记本上就可能布局错乱。而PDF作为一种“数字纸张”标准，一旦生成，其版面、字体、图片都是内嵌且固定的，在任何设备上打开都能保证一致的视觉呈现。这对于合同、发票、报告、证书等需要严肃交付和存档的文档来说，是刚需。

过去，这类需求通常交给后端处理。服务器用无头浏览器（如Puppeteer）渲染HTML，再转成PDF，然后流式传输给前端。这种方式稳定，但增加了服务器负载和网络往返延迟。随着现代浏览器能力的增强，特别是JavaScript API的丰富，越来越多的转换工作可以“下沉”到客户端浏览器中完成。这带来了几个显著好处：减轻服务器压力、实现离线转换、提升用户体验（无等待），并且能直接利用用户浏览器已加载的DOM和样式，保证“所见即所得”。

那么，在浏览器这个沙盒环境里，我们到底有哪几种武器可以把HTML变成PDF？每种方式的能力边界、适用场景和隐藏的坑又是什么？今天，我们就抛开那些笼统的介绍，深入代码和细节，把几种主流方案掰开揉碎了讲清楚。

2. 方案一：原生window.print()与打印样式

这是最古老、最直接，也最容易被低估的方案。很多人觉得window.print()弹出来的是打印对话框，和PDF不直接相关。但实际上，在现代操作系统中，选择“打印”目标时，几乎都包含“另存为PDF”的虚拟打印机。因此，通过引导用户触发打印并选择“保存为PDF”，是一种零依赖的转换方式。

2.1 核心原理与调用方式

其本质是调用操作系统的打印接口。浏览器会将当前文档根据打印CSS媒体查询进行重新布局，然后交由系统的打印处理器处理，其中就包括生成PDF文件。

基础调用简单到令人发指：

// 直接调用，会弹出系统打印对话框 window.print(); // 通常我们会在一个按钮点击事件中调用 document.getElementById('printBtn').addEventListener('click', () => { window.print(); });

用户点击按钮后，会弹出系统标准的打印预览对话框，在那里可以选择“目标打印机”为“另存为PDF”，然后设置页面、边距等选项后保存。

2.2 灵魂所在：打印样式表（CSS@media print）

直接打印网页往往惨不忍睹：导航栏、侧边栏、广告、按钮等屏幕交互元素全部会被打印出来。因此，打印样式表是让这一方案可用的关键。你需要在CSS中定义专门针对打印媒体的样式。

/* 在屏幕显示时隐藏的元素，在打印时也隐藏 */ .screen-only { display: none; } /* 打印样式 */ @media print { /* 1. 隐藏所有不需要打印的元素 */ header, footer, nav, .ad-banner, .no-print { display: none !important; } /* 2. 调整主体内容布局，通常改为块级显示，清除浮动 */ body { font-size: 12pt; /* 使用点(pt)作为单位更符合打印习惯 */ line-height: 1.5; margin: 0; /* 打印对话框本身有边距设置 */ padding: 0; color: black !important; /* 强制黑色打印，节省墨水且更清晰 */ background: white !important; } /* 3. 处理链接，将URL显示在文本后 */ a[href]::after { content: " (" attr(href) ")"; font-size: 90%; font-weight: normal; } /* 4. 避免内容在页面底部被切断 */ h1, h2, h3, h4 { page-break-after: avoid; } table, figure, img { page-break-inside: avoid; } /* 5. 确保容器有宽度且不溢出 */ .print-content { width: 100% !important; max-width: none !important; box-shadow: none !important; } }

关键技巧：使用!important是一个实用但需谨慎的策略。因为打印样式需要覆盖可能内联或权重很高的屏幕样式，!important可以确保生效。但更好的做法是构建一个权重足够高的打印样式选择器。

2.3 进阶控制：@page规则与页面属性

CSS的@page规则允许你定义打印页面的尺寸、边距和方向，这对于生成格式规范的PDF至关重要。

@media print { @page { /* A4尺寸，纵向 */ size: A4 portrait; /* 页边距。注意：许多浏览器有最小边距限制（如Chrome约0.4英寸） */ margin: 15mm 10mm; /* 定义页面左上角和右上角的页眉内容（需要浏览器支持） */ margin-top: 25mm; /* 为页眉留出空间 */ @top-left { content: element(pageHeader); } } /* 定义一个固定在每页顶部的页眉 */ .page-header { position: running(pageHeader); text-align: center; border-bottom: 1px solid #ccc; width: 100%; } /* 强制分页 */ .page-break-before { page-break-before: always; } .page-break-after { page-break-after: always; } }

注意：@page规则和running()函数对于页眉页脚的支持，在不同浏览器间差异很大。Chrome/Edge支持相对较好，但Firefox和Safari的支持可能不完整或行为不一致。在实际项目中，更稳定的做法是将页眉页脚作为文档内容的一部分，通过巧妙的布局和分页控制来实现。

2.4 实战心得与避坑指南

1. “所见即所得”的陷阱：打印样式和屏幕样式是两套体系。你必须为打印专门设计和测试。一个常见的坑是，屏幕使用Flexbox或Grid布局，元素高度由内容撑开。但在打印时，如果内容超过一页，布局模型可能会产生意想不到的断裂。解决方案：对于打印文档，倾向于使用更传统的块级布局（display: block）和明确的宽度控制。

2. 图片和背景色：默认情况下，浏览器可能不会打印背景色和背景图（为了省墨）。如果你的设计依赖这些，需要在打印样式中显式声明：

   @media print { * { -webkit-print-color-adjust: exact !important; /* Chrome, Safari */ print-color-adjust: exact !important; /* 标准属性 */ } .colored-bg { background-color: #f0f0f0 !important; } }

   即使这样，某些浏览器或用户设置仍可能覆盖此选项。对于关键信息，避免仅用颜色区分，应结合文字或图案。

3. 字体嵌入问题：如果使用了网络字体（如Google Fonts），打印时可能因网络或权限问题无法加载，导致回退到默认字体。解决方案：对于要求严格的文档，考虑将关键字体通过@font-face并以base64格式嵌入到打印样式表中，或者使用PDF生成库来确保字体嵌入。

4. 交互内容丢失：PDF是静态的。所有JavaScript交互、视频、动画在PDF中都会失效。表单输入框可能会被保留为可填写状态（取决于浏览器和PDF阅读器），但行为不可控。

适用场景：

• 对PDF格式要求不高，只需要一个可读的存档版本。
• 项目不能或不想引入任何第三方库。
• 转换操作由用户主动触发，并且可以接受一个系统打印对话框的交互流程。
• 用于“打印此页”功能，PDF只是其输出选项之一。

不适用场景：

• 需要后端静默生成PDF并发送邮件或存档。
• 对PDF的页码、页眉页脚、水印、加密等有精确要求。
• 需要批量或自动化转换。

3. 方案二：html2canvas+jsPDF的“截图拼接”法

这是前端领域非常流行的一种“曲线救国”方案。其核心思路分两步：

1. html2canvas：将指定的DOM元素（或整个body）渲染到一个<canvas>画布上，本质上是对网页视觉外观的一次“截图”。
2. jsPDF：创建一个新的PDF文档对象，然后将上一步得到的Canvas图像，以图片的形式添加到PDF的每一页中。

3.1 工作原理深度拆解

html2canvas的工作原理并非真正“截图”，而是遍历目标DOM树，计算每个节点的样式，然后在Canvas的2D上下文中重新绘制出来。这意味着它受限于Canvas的渲染能力：

• 能较好支持：CSS3颜色、渐变、边框、阴影、文本（部分）、图片。
• 支持有限或有问题：CSSclip-path、mix-blend-mode等高级混合模式、某些字体渲染细节、滚动条、插件内容（如Flash）。
• 完全不支持：跨域图片（除非服务器配置CORS）、<iframe>内的内容、系统字体（需要确保Web字体已加载）。

jsPDF则是一个纯JavaScript的PDF生成库，可以在浏览器或Node.js中创建和编辑PDF文件。它提供API来添加文本、图片、矢量图形等。

3.2 基础实现与代码示例

首先，安装或引入这两个库。可以通过CDN或npm安装。

<!-- CDN方式 --> <script src="https://cdnjs.cloudflare.com/ajax/libs/html2canvas/1.4.1/html2canvas.min.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/jspdf/2.5.1/jspdf.umd.min.js"></script>

// 假设我们有一个id为`content`的DOM元素需要转换 const element = document.getElementById('content'); const pdf = new jspdf.jsPDF('p', 'mm', 'a4'); // 纵向，毫米单位，A4纸 html2canvas(element, { scale: 2, // 提高渲染缩放倍数以获得更清晰的图片 useCORS: true, // 尝试加载跨域图片（需服务器配合） logging: false, // 关闭调试日志 backgroundColor: '#ffffff' // 确保背景为白色 }).then(canvas => { const imgData = canvas.toDataURL('image/jpeg', 1.0); // 将canvas转为JPEG格式的DataURL const imgWidth = 190; // PDF中图片宽度，A4纸宽210mm，左右留白10mm const pageHeight = 297; // A4纸高297mm const imgHeight = (canvas.height * imgWidth) / canvas.width; // 等比例计算图片高度 let heightLeft = imgHeight; let position = 0; // 图片在PDF中的起始Y坐标 // 第一页 pdf.addImage(imgData, 'JPEG', 10, position, imgWidth, imgHeight); heightLeft -= pageHeight; // 如果内容高度超过一页，需要分页 while (heightLeft > 0) { position = heightLeft - imgHeight; // 注意：jsPDF的坐标原点在左上角 pdf.addPage(); // 将图片的剩余部分添加到新页面，通过调整Y坐标和高度实现“切割” pdf.addImage(imgData, 'JPEG', 10, position, imgWidth, imgHeight); heightLeft -= pageHeight; } pdf.save('document.pdf'); // 触发浏览器下载 });

3.3 核心难题：分页与内容切割

上面的示例代码展示了简单的分页逻辑，但它有一个致命问题：它是在切割一张图片。如果分页恰好切在了一行文字的中间，那么这行文字就会在上一页的底部被截断，在下一页的顶部显示剩余部分，阅读体验极差。

这是html2canvas+jsPDF方案最大的痛点。为了解决它，社区和实践中有以下几种思路：

1. 手动分页（推荐）：这是最可靠但最繁琐的方法。你需要在HTML内容层面就预先定义好分页。

   <div id="content"> <div class="page">第一页内容...</div> <div class="page-break"></div> <!-- 只是一个标记 --> <div class="page">第二页内容...</div> </div>

   在CSS中，为分页标记设置样式：

   @media screen { .page-break { display: none; } } /* 或者通过jsPDF循环处理每个.page元素 */

   然后，在JavaScript中，不再对整个#content渲染一次，而是循环对每一个.page元素单独调用html2canvas，将每个元素生成的图片依次添加到PDF的不同页中。这样可以保证每一页的内容都是完整的。

2. 使用html2canvas的onclone选项：这个回调函数允许你在克隆的DOM树被渲染到Canvas之前，动态地修改它。你可以编写一个算法，遍历克隆的DOM，计算内容高度，并在适当的位置插入分页符（比如通过添加一个足够高的透明<div>来将后续内容“挤”到下一页的画布区域外）。但这需要非常精细的布局计算，复杂度很高。

3. 依赖第三方封装库：有一些库如html2pdf.js，它封装了html2canvas和jsPDF，并尝试提供更智能的分页功能。但其分页逻辑依然是启发式的，对于复杂布局可能失效，需要仔细测试。

3.4 字体、清晰度与性能优化

• 字体：html2canvas渲染的是视觉外观。只要浏览器能正确显示字体（无论是系统字体还是已加载的Web字体），它就能被“画”到Canvas上。但最终PDF里保存的是图片，文字不可被选中、搜索或复制。如果你需要PDF内的文字可检索，此方案不适用。

• 清晰度：通过设置html2canvas的scale参数（如设为2或3），可以在更高分辨率下渲染Canvas，然后以原始尺寸放入PDF，从而提高清晰度。但这会显著增加内存占用和渲染时间，对于大文档可能导致浏览器卡顿甚至崩溃。需要在清晰度和性能间权衡。

• 性能：渲染一个复杂的、长的DOM树到Canvas是一个CPU密集型操作。对于超过10页的内容，转换过程可能会让页面暂时失去响应。最佳实践是：

  • 只转换必要的部分，隐藏或移除无关的DOM节点。
  • 显示一个“正在生成PDF...”的加载提示。
  • 考虑使用Web Worker在后台线程执行转换任务（注意html2canvas可能涉及DOM操作，在Worker中有限制）。

适用场景：

• 需要将带有复杂CSS3样式、阴影、圆角等现代UI效果的页面保存为PDF。
• 对文字可选择性、可搜索性没有要求。
• 内容长度可控，或可以接受手动分页的额外开发成本。
• 项目已重度依赖前端，希望完全在客户端完成。

不适用场景：

• 生成需要文字检索、复制粘贴的正式文档（如合同、论文）。
• 内容超长，且无法接受手动分页的复杂工作。
• 对PDF文件大小非常敏感（图片格式的PDF通常比矢量文本的PDF大很多）。

4. 方案三：@react-pdf/renderer与声明式PDF生成

如果你在使用React技术栈，并且对PDF的质量和可维护性有较高要求，那么@react-pdf/renderer是一个颠覆性的选择。它允许你用写React组件的方式来声明式地构建PDF文档。

4.1 理念革新：从“转换”到“生成”

前两种方案都是“转换”：将已有的、为屏幕展示而优化的HTML，想办法适配到PDF的约束中。而@react-pdf/renderer是“生成”：你从一开始，就是为了生成PDF而编写代码。它提供了一套类似React Native的组件（如<Document>,<Page>,<Text>,<View>,<Image>等），专门用于描述PDF页面的结构。

import React from 'react'; import { Document, Page, Text, View, StyleSheet } from '@react-pdf/renderer'; // 定义PDF样式 const styles = StyleSheet.create({ page: { flexDirection: 'column', backgroundColor: '#E4E4E4', padding: 30, }, section: { margin: 10, padding: 10, flexGrow: 1, }, title: { fontSize: 24, textAlign: 'center', marginBottom: 20, }, body: { fontSize: 12, lineHeight: 1.5, }, }); // 创建一个PDF文档组件 const MyDocument = () => ( <Document> <Page size="A4" style={styles.page}> <View style={styles.section}> <Text style={styles.title}>我的PDF报告</Text> <Text style={styles.body}> 这是一段在PDF中生成的文本。文字是矢量的，可以被选中和搜索。 样式使用Flexbox布局模型，与React Native非常相似。 </Text> </View> </Page> </Document> ); export default MyDocument;

4.2 核心优势与能力

1. 矢量文本与可搜索性：生成的PDF中的文字是真正的文本对象，而非图片。这意味着文件体积小、无限缩放不模糊，并且可以被PDF阅读器搜索、复制、朗读（辅助功能）。
2. 精确的布局控制：基于Flexbox的布局模型，对于多页文档的分页控制非常精准。组件在渲染时就知道自己的尺寸，当内容超出<Page>高度时，库会自动创建新页，并智能地避免在行内元素中间分页（大多数情况下）。
3. 样式与主题：支持完整的样式定义（StyleSheet.create），包括字体、边距、颜色、边框等，并且样式支持继承和组合。
4. 动态数据集成：与任何React组件一样，你可以方便地注入动态数据（来自state、props、API请求等）。
5. 丰富的组件：除了基础组件，还支持<Link>、<Note>（注释）、<Canvas>（自定义绘制）、页眉页脚、页码等。

4.3 在浏览器中渲染与下载

虽然@react-pdf/renderer常用于Node.js服务端生成PDF，但它也完全支持在浏览器中运行。

import React from 'react'; import ReactDOM from 'react-dom/client'; import { pdf } from '@react-pdf/renderer'; import MyDocument from './MyDocument'; const App = () => { const handleDownload = async () => { // 1. 将React组件渲染为PDF Blob const blob = await pdf(<MyDocument />).toBlob(); // 2. 创建下载链接 const url = URL.createObjectURL(blob); const link = document.createElement('a'); link.href = url; link.download = 'my-document.pdf'; // 3. 触发下载 document.body.appendChild(link); link.click(); // 4. 清理 document.body.removeChild(link); URL.revokeObjectURL(url); }; return ( <div> <button onClick={handleDownload}>下载PDF</button> </div> ); }; const root = ReactDOM.createRoot(document.getElementById('root')); root.render(<App />);

4.4 与现有HTML内容的结合：混合生成策略

一个常见的挑战是：我的应用主体是传统的HTML网页，只有一部分内容（比如一个数据可视化图表或一份格式化报告）需要用高质量PDF生成。这时可以采用混合策略：

1. 数据驱动：不转换HTML，而是提取HTML背后的结构化数据（JSON），然后将这些数据传递给一个专用的<ReportPDF>组件来生成PDF。这是最清晰、耦合度最低的方式。
2. 服务端渲染：如果PDF内容非常复杂，或者生成过程耗时，可以考虑在服务端用Node.js运行@react-pdf/renderer来生成PDF文件，然后提供下载链接给前端。
3. iframe嵌入与打印：对于已有的、样式复杂的HTML片段，可以将其放入一个隐藏的<iframe>，然后结合方案一（iframe.contentWindow.print()）来利用浏览器的打印功能。但这又回到了方案一的限制。

适用场景：

• React技术栈项目。
• 需要生成高质量、带可搜索文字、格式严谨的正式文档（如发票、合同、报告）。
• PDF的模板和结构相对固定，由数据驱动生成。
• 开发者对样式和布局有精细控制的需求。

不适用场景：

• 非React项目。
• 需要将任意、动态、样式极其复杂的已有HTML页面（比如一个完整的用户仪表盘）原封不动地转为PDF。这更适合用方案二或方案四。
• 对服务端渲染没有基础设施，且PDF生成逻辑非常重，不适合在用户浏览器中执行。

5. 方案四：Puppeteer无头浏览器控制

虽然Puppeteer通常被认为是后端（Node.js）工具，但其核心是通过DevTools协议控制Chromium。理论上，我们可以通过一些方式在浏览器环境中引入或模拟Puppeteer的部分功能，但这非常规且复杂。更常见的模式是，当需要在浏览器端触发一个高质量的、自动化的HTML转PDF任务时，实际工作是由一个后端服务完成的，前端只负责发起请求。

不过，理解Puppeteer的方案至关重要，因为它是目前服务端生成PDF的事实标准，代表了“转换”类方案的最高质量。

5.1 为什么Puppeteer的PDF质量高？

因为Puppeteer驱动的就是一个完整的、无界面的Chrome浏览器。它：

• 拥有完整的渲染引擎：支持所有现代CSS、JavaScript、Web字体。
• 实现真正的打印模拟：其page.pdf()方法生成PDF的原理，与Chrome浏览器的“打印为PDF”功能几乎一致，质量极高。
• 支持@pageCSS规则：对页眉、页脚、页边距、尺寸的控制非常精准。
• 生成可搜索的文本：PDF内嵌字体，文字可选中。
• 处理复杂交互：可以在生成PDF前执行页面上的JavaScript，等待网络请求、动画完成，确保渲染的是最终状态。

5.2 前端-后端协作模式

典型的架构是，前端准备数据或标识，向后端API发起请求。

// 前端：发送生成PDF的请求 async function generatePDF(htmlContent, options) { const response = await fetch('/api/generate-pdf', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ html: htmlContent, // 或者是一个URL，由后端去抓取 pdfOptions: options // 如格式、边距等 }), }); if (response.ok) { const blob = await response.blob(); const url = URL.createObjectURL(blob); const a = document.createElement('a'); a.href = url; a.download = 'document.pdf'; a.click(); URL.revokeObjectURL(url); } else { throw new Error('PDF生成失败'); } } // 后端（Node.js + Express + Puppeteer示例） const express = require('express'); const puppeteer = require('puppeteer'); const app = express(); app.use(express.json()); app.post('/api/generate-pdf', async (req, res) => { const { html, pdfOptions = {} } = req.body; const browser = await puppeteer.launch({ headless: 'new', // 使用新的Headless模式 args: ['--no-sandbox', '--disable-setuid-sandbox'] // 服务器环境可能需要 }); const page = await browser.newPage(); // 方法A：直接设置HTML内容 await page.setContent(html, { waitUntil: 'networkidle0' }); // 方法B：导航到一个URL // await page.goto(url, { waitUntil: 'networkidle0' }); const pdfBuffer = await page.pdf({ format: 'A4', printBackground: true, // 打印背景图形 margin: { top: '20mm', right: '15mm', bottom: '20mm', left: '15mm' }, ...pdfOptions // 合并传入的自定义选项 }); await browser.close(); res.setHeader('Content-Type', 'application/pdf'); res.setHeader('Content-Disposition', 'attachment; filename=document.pdf'); res.send(pdfBuffer); });

5.3 前端模拟与轻量级替代思考

纯粹在浏览器端运行Puppeteer是不现实的。但社区有一些探索：

• Puppeteer Web：这是一个实验性项目，尝试将Puppeteer的核心编译成WebAssembly在浏览器中运行。但它体积庞大，功能受限，且不稳定，不推荐用于生产环境。
• Service Worker + 简化渲染器：一种极致的思路是，在Service Worker中运行一个极度简化的HTML/CSS渲染器来生成PDF。这实现复杂度极高，且兼容性、性能都无法保证。

因此，对于必须在浏览器内完成、且要求达到Puppeteer质量的需求，目前几乎没有完美的纯前端方案。通常的妥协是：

1. 接受方案二（html2canvas）的局限性（图片、文字不可搜索）。
2. 采用方案三（@react-pdf/renderer），但前提是你能用其组件重写你的内容。
3. 利用云服务/Serverless函数：将Puppeteer运行在云端的Serverless函数（如Vercel Edge Functions, AWS Lambda, Cloudflare Workers）中，前端通过API调用。这本质上还是后端生成，但无需自己维护服务器。

5.4 安全与性能考量

即使在后端使用Puppeteer，也需注意：

• 安全：永远不要直接执行用户提交的未经验证的HTML或JavaScript，这会导致严重的XSS攻击甚至服务器被控制。必须对输入进行严格的清洗和沙箱隔离。
• 性能与资源：启动浏览器实例开销大。需要使用连接池、预热或无服务器方案来管理浏览器实例，避免每个请求都启动一个新的浏览器。
• 字体：确保无头浏览器环境中安装了生成PDF所需的所有字体，否则会回退到默认字体。

适用场景：

• 对PDF质量要求最高，需要完美还原网页效果。
• 需要处理包含复杂JavaScript交互的页面（如等待图表渲染完成）。
• 有后端支持，可以承担额外的服务器资源开销。
• 批量生成PDF任务。

不适用场景：

• 纯前端应用，无后端服务。
• 对延迟极其敏感，要求瞬时生成。
• 项目资源有限，无法维护Puppeteer服务端环境。

6. 方案对比与选型决策指南

为了更直观地对比，我将四个核心方案的关键特性总结如下：

6.1 如何选择？一个决策流程图

面对具体需求，你可以遵循以下思路：

1. 问：是否需要“完全无后端”的纯前端方案？

   • 是-> 进入第2步。
   • 否-> 直接选择Puppeteer (服务端)，这是质量、功能和可控性的黄金标准。

2. 问：PDF中的文字是否需要可被选中、搜索、复制？

   • 是-> 选择window.print()或@react-pdf/renderer。
     • 如果你的内容已经是网页，且能通过CSS媒体查询适配打印，选window.print()。
     • 如果你在用React，且愿意/能够用声明式组件描述PDF内容，选@react-pdf/renderer。
   • 否-> 选择html2canvas+jsPDF。它最适合保存带有复杂视觉效果的“页面快照”。

6.2 混合方案与进阶思考

在实际大型项目中，单一方案可能无法满足所有需求，混合使用是常态：

• 主方案用Puppeteer，备用方案用html2canvas：在服务器繁忙或离线情况下，前端降级为图片PDF生成，保证功能可用性。
• @react-pdf/renderer生成核心文档，html2canvas嵌入复杂图表：用React PDF生成文档主体和矢量文字，对于某些无法用PDF组件绘制的复杂动态图表，可以用html2canvas将其转为图片，再以<Image>形式插入PDF文档。
• 预生成与动态生成结合：对于不常变化的模板化PDF（如合同范本），可以在后端预生成好PDF文件存储起来。对于需要填充动态数据的，则实时调用Puppeteer或React PDF服务生成。

6.3 一个容易被忽略的细节：PDF的元数据和安全性

无论用哪种方案生成PDF，都不要忘记设置PDF的元数据（如标题、作者、主题），这能让文件更专业。在jsPDF和@react-pdf/renderer中都有相应的API。对于敏感文档，还可以考虑在生成时添加密码保护（jsPDF和Puppeteer支持），但这通常需要在服务端进行。

浏览器中HTML转PDF是一个看似简单，实则充满细节和权衡的领域。没有银弹，最好的方案永远取决于你的具体需求：质量、性能、复杂度、技术栈和基础设施。希望这篇近万字的拆解，能帮你看清每条路的路况和终点，做出最适合自己项目的选择。在实际动手前，务必用真实的数据和样式进行充分的测试，特别是分页和字体渲染，这两个地方最容易出现“买家秀和卖家秀”的差异。