chrome浏览器“打印→另存为pdf”最可靠，兼容性好、支持打印样式、保留交互状态；puppeteer适合自动化场景但需处理加载时机和字体；html2canvas易失真不推荐长页面。
Chrome 浏览器直接打印为 PDF 最可靠
绝大多数网页转 PDF 的需求，用 Chrome 自带的「打印 → 另存为 PDF」就能解决，不需要装插件或跑脚本。它兼容性好、支持 CSS 媒体查询（比如 @media print）、能保留基础交互元素（如折叠菜单展开后的状态），而且生成速度快。
常见错误现象：另存为 PDF 后页面错位、字体缺失、背景色被砍掉、分页混乱——大概率是网页没适配打印样式，或用了 display: none 或 visibility: hidden 隐藏了关键内容。
- 按
Ctrl+P（Win）或Cmd+P（Mac）呼出打印面板 - 目标打印机选
另存为 PDF，别选「Microsoft Print to PDF」这类系统虚拟打印机（容易丢 CSS） - 勾选
背景图形（否则灰色底色、图片背景全白） - 在
更多设置里调高缩放（默认 80% 常导致文字过小） - 如果网页有动态内容（如 React 渲染的表格），先手动滚动到底部、点开所有折叠项，再打印
用 Puppeteer 生成 PDF 要小心页面加载时机
自动化场景下必须用代码生成 PDF（比如定时导出报表），puppeteer 是目前最稳的选择，但它默认不等 JS 渲染完成就截图，容易导出空白页或缺数据。
使用场景：需要批量导出、带登录态、依赖异步接口或 WebAssembly 的页面。
立即学习“前端免费学习笔记（深入）”；
性能影响：每个 PDF 生成约消耗 100–300MB 内存，连续生成 5 个以上建议复用 browser 实例，别每次 launch + close。
- 别用
page.goto(url)后直接pdf()，改用page.waitForNetworkIdle()或监听特定元素出现 - 显式设置
waitUntil: 'networkidle0'（但注意：有些 SPA 会持续发心跳请求，得配合timeout） - 字体问题：Linux 服务器常缺中文字体，PDF 里中文变方框，需提前安装
fonts-wqy-zenhei或挂载字体文件 - 路径权限：
page.pdf({ path: '/tmp/report.pdf' })要确保 Node.js 进程对/tmp有写权限
html2canvas + jsPDF 容易失真且不推荐用于长页面
html2canvas 是纯前端方案，适合简单静态页，但遇到 transform、svg、跨域图片、iframe 或滚动容器时，大概率截断、模糊或白屏。它本质是“截图”，不是“渲染 PDF”。
错误现象：html2canvas 返回的 canvas 空白、文字锯齿严重、表格列宽崩坏、固定定位元素位置错乱。
- 别对
document.body整体截图，先用overflow: visible临时撑开容器，再截指定div -
jsPDF的addHTML已废弃，html2canvas输出的 canvas 要用addImage，但单张图超过 A4 尺寸会压缩变形 - 长页面必须分页拼接，但
html2canvas不提供原生分页逻辑，自己算高度极易出错 - 移动端 Safari 对
html2canvas支持极差，iOS 上常卡死或返回空 canvas
PDF 导出后字体/样式异常的三个检查点
无论用哪种方式，导出后字体发虚、CSS 不生效、中文显示为方块，问题通常不在转换工具本身，而在原始 HTML 的加载链路上。
兼容性影响：某些字体 CDN（如 Google Fonts）在无网络环境下无法回退，@font-face 没设 font-display: swap 会导致 PDF 里字体直接失效。
- 检查
link[rel="stylesheet"]是否全部加载完成——Puppeteer 中可用page.$$eval('link[rel="stylesheet"]', els => els.map(e => e.sheet?.cssRules?.length))验证 - 内联关键 CSS：把
@media print样式用<style></style>标签写死在head里，避免外部 CSS 加载超时 - 字体路径别用相对 URL：PDF 生成时当前路径是服务端或浏览器沙箱，
url('./fonts/simhei.woff2')极可能 404，改用 base64 内联或绝对 URL
真正麻烦的不是怎么转，而是网页本身有没有为“可打印”做准备——比如没写 @media print、JS 渲染依赖用户滚动触发、字体加载逻辑耦合了 window.onload。这些细节不提前处理，换十种工具都救不回来。
