HTML转PDF无法保留交互元素，主流工具生成的PDF均为静态快照；仅wkhtmltopdf支持基础AcroForm表单，pdf-lib可手动添加字段，但需坐标计算与后端解析。
HTML 转 PDF 时交互元素（如按钮、表单、JS 行为）根本不会保留
直接告诉你结论：html2pdf.js、wkhtmltopdf、Puppeteer 这些主流工具生成的 PDF 是静态快照，所有 <button></button>、<input type="checkbox">、onclick、addEventListener 全部失效。PDF 不是网页，它不执行 JS，也不响应点击——这是格式本质决定的，不是配置能绕过的。
想让 PDF “看起来有交互”，只能靠 PDF 自身支持的表单域（AcroForm）
PDF 规范里确实有可填写的表单字段（文本框、复选框、下拉菜单），但它们必须由 PDF 生成工具显式创建，不能从 HTML 的 <input> 自动映射过去。目前只有少数方案能有限支持：
-
Puppeteer完全不支持生成带 AcroForm 的 PDF —— 它输出的是“打印快照” -
wkhtmltopdf通过--forms参数可将<input type="text">、<select></select>渲染为 PDF 表单域，但仅限基础类型，且不支持 JS 动态逻辑（比如“勾选 A 则显示 B 区域”） -
pdf-lib+ 手动构造：先用 Puppeteer 渲染 HTML 为 PDF 页面，再用pdf-lib加载该 PDF，在指定位置插入 AcroForm 字段。这需要你精确计算坐标、管理字段名、处理导出数据逻辑——适合小范围定制，不适合整页复杂表单
常见“伪交互”需求的真实替代方案
多数人所谓“保交互”，其实是想实现这几类效果，对应有更务实的做法：
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
- 用户填完在线表单 → 下载一份“已填好”的 PDF 报告：服务端用模板引擎（如
Jinja2/handlebars）+WeasyPrint或pdfkit渲染最终静态 PDF，把用户输入值填进去即可 - PDF 需要签名或手写标注：生成 PDF 后，用
pdf-lib添加签名域（acroField），再配合前端canvas手写板截图，最后嵌入 PDF 图像层 - 希望 PDF 点击跳转到网址或页面锚点：PDF 支持内部链接（
Linkannotation）和 URI 动作，weasyprint会自动把<a href="https://..."></a>转成可点击链接；wkhtmltopdf也支持，但需确保启用--enable-local-file-access和链接协议合法
容易被忽略的关键限制
即使你用 wkhtmltopdf --forms 生成了带表单域的 PDF，也要注意：
立即学习“前端免费学习笔记（深入）”；
- PDF 查看器兼容性差：Adobe Acrobat 可编辑，但 macOS 预览、Chrome 内置 PDF 查看器、手机系统 PDF 阅读器大多只读，无法填写
- 字段值无法通过 JS 读取：生成后的 PDF 里，你不能再用
document.getElementById(...).value拿数据——必须用后端 PDF 解析库（如pdf-parse或pdf-lib的getFormValues()）提取 - 样式塌陷严重：CSS 中
flex、grid、position: fixed在 PDF 渲染中几乎全部失效，表单控件尺寸、对齐、字体渲染与浏览器差异极大，必须用 table + inline style 做兼容布局
const pdfDoc = await PDFDocument.load(existingPdfBytes);
const form = pdfDoc.getForm();
const textField = form.createTextField('fullName');
textField.addToPage(page, { x: 100, y: 600, width: 300, height: 24 });
// 注意：x/y 是 PDF 坐标系（左下为原点），单位是点（1/72 英寸），和 CSS px 不等价
实际做下来，所谓“保交互”基本等于放弃 HTML 直出思维，改用 PDF 原生表单工作流——要么接受静态输出，要么在生成环节就切换到 PDF 构建逻辑。 
