HTML转PDF在浏览器中本质单线程，所谓“多线程”实为服务端多进程（如puppeteer子进程隔离）或客户端Web Worker预处理；真正提效关键在模板预编译、内联字体、精准printOptions及合理并发数。
HTML 转 PDF 本身不支持多线程
浏览器环境（包括 window.print()、jsPDF、html2canvas + jsPDF）是单线程的，无法真正并行执行多个 HTML → PDF 转换任务。所谓“多线程”，实际是服务端行为或客户端伪并发——比如用 Web Worker 拆分渲染步骤，但 PDF 生成主逻辑（尤其是布局、字体加载、分页）仍受主线程阻塞。
Node.js 环境下可用多进程替代多线程
在服务端用 puppeteer 或 playwright 批量转 PDF 时，“多线程”应理解为多进程隔离运行，避免内存和 Chromium 实例冲突：
-
puppeteer.launch({ headless: true })每次调用都启一个新浏览器实例，开销大；更稳妥的是复用单个browser实例，用browser.newPage()创建多个页面并发处理 - 若需真正隔离（防崩溃传染），可用
child_process.fork()启多个子进程，每个进程跑一个puppeteer实例，通过process.send()通信 - 注意内存限制：
--max-old-space-size=4096可能需加到 Node 启动参数，否则大量 HTML 渲染易 OOM
const { fork } = require('child_process');
const tasks = ['report1.html', 'report2.html', 'report3.html'];
tasks.forEach((file, i) => {
const cp = fork('./pdf-worker.js');
cp.send({ file, output: `out-${i}.pdf` });
});
前端用 Web Worker 只能辅助预处理，不能直接转 PDF
Web Worker 可脱离主线程做 HTML 字符串拼接、数据计算、CSS 提取等，但以下操作仍必须回主线程：
- 调用
document.body.innerHTML = htmlStr（DOM 操作不可跨线程） - 触发
html2canvas渲染（依赖 canvas 和 DOM） - 调用
jsPDF().html()（内部仍走 DOM 解析）
典型错误：在 Worker 里直接 import html2canvas 并调用 —— 会报 document is not defined 或 Cannot access 'window' before initialization。
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
立即学习“前端免费学习笔记（深入）”；
真正提升批量 PDF 生成效率的关键点
与其纠结“多线程”，不如聚焦这三处瓶颈：
- HTML 模板编译：用
handlebars或lodash.template预编译，避免每次eval字符串 - 字体加载：Puppeteer 中用
page.addStyleTag({ content: '@font-face {...}' })内联关键字体，避免网络请求阻塞 - PDF 输出裁剪：用
printOptions = { format: 'A4', printBackground: true, margin: { top: 0 } }显式控制，减少重排重绘
并发数不是越多越好。实测中，8 核 CPU 上 puppeteer 并发 3–5 个页面通常吞吐最高；再多反而因 GC 和内存竞争导致平均耗时上升。
