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 拼出来的，得先等加载完成再手动触发打印 - 默认禁用本地资源（如
./style.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 引擎会把它当装饰性内容剥离。这种细节，只有真去复制、搜、朗读一遍才暴露出来。
