wkhtmltopdf 是生成可搜索PDF最可靠方案，因其基于WebKit将HTML标签转为矢量文本图层，支持复制、搜索与屏幕阅读；需加--enable-local-file-access参数并指定中文字体如Noto Sans CJK SC。

用 wkhtmltopdf 生成可搜索 PDF 最可靠

HTML 转可搜索 PDF 的核心是：必须保留文本的矢量信息，不能转成图片。wkhtmltopdf 是目前最成熟的选择，它基于 WebKit 渲染，直接把 HTML 中的

、

等标签转为真实文本图层，复制、搜索、屏幕阅读器都能正常工作。

常见错误是用截图工具（如 html2canvas + jsPDF）——那本质是把页面画成 PNG 再塞进 PDF，结果是「看起来像 PDF，实际是张图」，Ctrl+F 搜不到任何字。

• Windows/macOS/Linux 全平台有预编译二进制，无需编译
• 支持 CSS @media print、自定义页眉页脚、目录生成
• 关键参数 --enable-local-file-access 必须加，否则本地 file:// 路径的 CSS/JS 加载失败
• 中文需额外指定字体：用 --font-family "Noto Sans CJK SC" 或确保系统已安装支持 Unicode 的字体

Chrome DevTools “Print to PDF” 适合临时调试

开发阶段快速验证是否可搜索，比配 wkhtmltopdf 更快：打开 HTML 文件 → F12 → Ctrl+P（或 Cmd+P）→ 选择“Save as PDF” → 勾选“Background graphics” → 保存。

这个 PDF 是 Chrome 实际渲染结果，只要你在页面里写的文字没被转成 Canvas 或 SVG path，就一定是可搜索的。但注意：

• 不能自动化批量处理（无命令行接口）
• 不支持 JS 动态渲染后的内容 —— 如果 document.body.innerHTML 是 JS 拼出来的，得先等加载完成再手动触发打印
• 默认禁用本地资源（如 ./s

  

  tyle.css），需在地址栏输入 chrome://flags/#enable-local-file-accesses 启用对应 flag（Chrome 120+ 已移除该 flag，改用 file:// 协议打开时加启动参数 --unsafely-treat-insecure-origin-as-secure="file://"）

避免 pdfkit / weasyprint 等纯 Python 库踩坑

pdfkit 只是 wkhtmltopdf 的 Python 封装，没问题；但 weasyprint 和 reportlab 从 HTML 解析后重建布局，对复杂 CSS（Flex/Grid/position: sticky）支持弱，容易丢文本或转成路径。

实测问题包括：

• weasyprint 把 中文 渲染成 glyph 而非 Unicode 字符，导致复制粘贴乱码
• 含 @import url("xxx.css") 的样式表可能被忽略，文本变黑体且不可搜
• 不支持 transform: rotate() 内的文字搜索（旋转后坐标系错乱）

如果非要用 Python，建议用 subprocess 调 wkhtmltopdf 二进制，而非依赖解析型库：

import subprocess
subprocess.run([
    'wkhtmltopdf',
    '--enable-local-file-access',
    '--font-family', 'Noto Sans CJK SC',
    'input.html',
    'output.pdf'
])

检查 PDF 是否真可搜索的三步法

生成完别急着交出去，立刻验证：

• 用 Adobe Acrobat Reader 打开 → Ctrl+F 输入页面中任意连续 3 个汉字，看能否定位
• 用 macOS 预览打开 → 选中一段文字 → 右键“查找” → 若弹出“未找到匹配项”，说明文本图层丢失
• 终端执行 pdfinfo output.pdf，确认输出里有 Tagged PDF: no 是正常的（Tagged 是无障碍标准，不是可搜索前提）；但若出现 Form: none 且 Pages: 1 下文字全无法选中，基本就是被光栅化了

最隐蔽的问题：CSS 里写了 -webkit-text-stroke: 1px transparent 或 text-shadow 过重，某些 PDF 引擎会把它当装饰性内容剥离。这种细节，只有真去复制、搜、朗读一遍才暴露出来。