使用Chromium无头模式将HTML转PDF时，即使设定了A4横向尺寸与零边距，仍可能意外生成空白第二页——根本原因常是CSS中height: 100%在嵌套块中引发的隐式溢出，导致内容高度超过可用页面空间。
使用chromium无头模式将html转pdf时，即使设定了a4横向尺寸与零边距，仍可能意外生成空白第二页——根本原因常是css中height: 100%在嵌套块中引发的隐式溢出，导致内容高度超过可用页面空间。
在HTML转PDF的实际工程中，“严格单页输出”看似简单，实则极易因CSS排版模型与PDF分页引擎的差异而失败。你提供的示例中，核心意图明确：用CSS Grid布局8个等宽卡片，填满A4横向（841pt × 594pt），并确保渲染结果恰好占据一页PDF。但执行chrome --headless --print-to-pdf后却出现一页内容 + 一页空白，这并非Chrome Bug，而是典型的“高度计算失准”现象。
关键症结在于这段样式：
.item div {
padding: 2em;
text-align: left;
overflow-y: hidden;
height: 100%; /* ← 问题根源 */
}表面看，.item已设height: 100%（即继承容器高度），再给其子div也设height: 100%似乎合理。但CSS中height: 100%要求父元素具有明确的高度值（非auto），而此处.item的高度虽声明为100%，其父容器.container的height: calc(594pt - 2px)虽为定值，却忽略了padding和border的叠加影响——更重要的是，2em的上下内边距会直接增加子div的总高度（content + padding），当该总高度略微超过.item的可用高度时，浏览器渲染层会判定内容“溢出”，触发分页引擎插入新页——即使视觉上仅超出几像素，也会导致空白页产生。
✅ 正确解法：移除.item div的height: 100%，改用flex或grid内部流式控制，并显式约束最大高度：
立即学习“前端免费学习笔记（深入）”；
.item {
display: flex;
flex-direction: column;
height: 100%;
}
.item div {
padding: 2em;
text-align: left;
overflow-y: auto; /* 或 hidden，视需求而定 */
flex: 1; /* 自动填充剩余空间，不硬性设高 */
}同时建议强化页面级防御措施：
- ✅ 使用
@page { size: A4 landscape; margin: 0; }+body { margin: 0; min-height: 100vh; } - ✅ 避免
em/rem单位在分页敏感区域（易受字体加载、缩放影响），优先用px或pt - ✅ 在Chrome命令中追加
--force-device-scale-factor=1防止DPI缩放干扰尺寸计算 - ✅ 添加
<meta name="viewport" content="width=device-width, initial-scale=1.0">确保响应式行为可控
⚠️ 注意：WeasyPrint等纯服务端引擎对
height: 100%解析更严格，而Chromium基于Blink，对“隐式溢出”的容忍度更低——这意味着同一份HTML，在不同引擎下分页表现可能迥异。生产环境务必锁定渲染引擎并做跨版本回归测试。
最终验证逻辑：导出后用pdfinfo output.pdf检查页数，或用qpdf --show-npages output.pdf确认是否严格为1页。单页PDF不仅是样式目标，更是文档交付的可靠性底线——从一个被忽略的height: 100%开始，到整套可审计的排版约束体系，正是专业PDF生成与“能用就行”之间的分水岭。
