Chrome/Edge按Ctrl+P导出PDF排版错乱，根本原因是浏览器默认禁用position:fixed、transform等CSS，忽略非@media print规则并强制分页；须显式添加@media print重置样式、禁用浮动定位、避免vh/vw单位、启用print-color-adjust精确打印背景，SVG/CSS建议转PNG嵌入。
直接用浏览器打印功能就能把 HTML 转成 PDF，效果稳定、零依赖、不丢样式——这是绝大多数静态网页场景下最靠谱的选择。
Chrome / Edge 浏览器按 Ctrl+P 导出 PDF 为什么有时排版错乱？
根本原因不是“导出失败”，而是浏览器默认将 HTML 当作“待打印页面”处理，会主动禁用部分 CSS（比如 position: fixed、transform、背景图）、忽略媒体查询中非 @media print 的规则，还会强制分页切断内容。
- 必须在 HTML 中显式添加
@media print块，重置关键样式：比如设body { margin: 0; padding: 0; }、关闭浮动和绝对定位 - 避免用
vh/vw单位控制高度，PDF 导出时视口尺寸不可靠；改用cm、in或固定px - 背景图默认不打印，需加
-webkit-print-color-adjust: exact;和print-color-adjust: exact; - 如果含大量 SVG 或 Canvas，建议先转为 PNG 再插入，否则可能空白或失真
pdfkit 和 puppeteer 在服务端生成 PDF 有什么实际差异？
pdfkit 是纯 Node.js 绘图库，不解析 HTML；puppeteer 是控制 Chrome 实例的自动化工具，真正渲染页面。两者适用边界非常清晰。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
-
pdfkit适合：结构固定、数据驱动的 PDF（如发票、报表），你手写布局逻辑，性能高、内存低，但无法直接喂 HTML 字符串 -
puppeteer适合：需真实渲染的 HTML（含 JS 交互后 DOM、CSS 动画帧、字体子集），但启动慢、内存占用大，且必须保证 Chrome 环境可用（Linux 服务器常缺字体或 sandbox 权限） - 常见坑：
puppeteer.launch()在无头模式下可能因缺少--no-sandbox或字体缓存失败而卡住；pdfkit默认不嵌入中文字体，中文会显示为方块
福昕/万兴等桌面软件导出 HTML 为 PDF 为什么偶尔内容缺失？
这类软件底层多数调用系统 WebKit 或封装了 Chromium，但做了重度裁剪和缓存优化——它们不是浏览器，而是“HTML 渲染快照工具”。
立即学习“前端免费学习笔记（深入）”；
- JavaScript 执行被限制或延迟：比如
setTimeout初始化的图表、fetch异步加载的数据，很可能在截图前就超时跳过 - 本地文件协议（
file://）路径下，跨域资源（如 CDN 字体、API 接口）一律被拦截，不会报错，只留空白 - 自定义字体（
@font-face）若未提供本地 .ttf/.woff 路径，或未开启“嵌入字体”选项，导出后变成默认宋体 - 解决办法：先导出为本地
http://127.0.0.1:8080/xxx.html服务，再用软件打开该地址，比直接双击 HTML 文件可靠得多
真正难的从来不是“怎么转”，而是“转出来的 PDF 是否能通过打印校验”——字体嵌入、CMYK 色彩空间、出血线、PDF/A 兼容性这些印刷级要求，所有前端方案都默认不处理，得靠专业 PDF 工具后期修补。
