3个坑坑死实战项目：签收单格式怎么改才不崩
版本升级后 API 全变了，你的签收单打印出来全是乱码？别慌，我踩过这个坑。在多个实战项目里，因为签收单格式没对齐，导致财务对账时数据错位，差点背锅。
很多老铁以为签收单就是个简单的 HTML 表格，或者一个 PDF 模板，填填数据就完事了。大错特错。在工程交付、物流流转、甚至内部审批流里，签收单是法律凭证。格式稍微歪一点，字段对不上，后面查账就是灾难。
今天这篇避坑指南，不整虚的。直接上真实项目里的血泪教训。咱们拆解三个最致命的坑：动态字段导致的布局崩塌、打印分页时的断行错乱、字体渲染导致的字符偏移。
读完这篇，你手里的签收单代码，至少能稳过三年。
坑一：动态字段让布局原地爆炸
现象描述
你是不是也遇到过这种情况？在代码里写死了签收单的表格结构，比如“货物名称”、“数量”、“单价”、“总价”。
平时测试数据都是短字符串，看起来挺整齐。结果上线后，客户发来的货物名称长达50个字，或者备注栏里塞了一整段合同条款。
瞬间，表格列宽被撑开，整个签收单变形。原本在一行的“签收人”和“日期”，被挤到了第二行。更可怕的是，如果这是用于打印的，A4纸可能都放不下，变成了两页，第一页只有表头，第二页才是内容。
根本原因
核心问题在于：CSS 布局没有考虑“极端输入”的情况。
很多开发习惯用 table 标签，然后给 td 设置固定的 width。当内容超过这个宽度时，浏览器默认行为是撑开单元格，而不是截断或换行。
另外，很多人喜欢用 flex 布局做签收单，以为这样更现代。但在打印场景下，flex 的表现极不稳定，特别是在不同浏览器（Chrome vs Edge vs Safari）的打印引擎里，计算结果可能不一致。
还有一个隐形杀手：字体加载失败。如果你的签收单用了特殊字体（比如某些工程专用的仿宋），而前端没有配置 @font-face 或者字体文件加载失败，浏览器会回退到默认字体。默认字体的字符宽度与专用字体不同，导致所有列宽计算全部作废。
正确写法对比
错误写法（固定宽度 + 默认换行）：
/* ❌ 错误示范：死板的固定宽度 */
.sign-table td {width: 100px; /* 无论内容多长，都强行占用100px，溢出就撑破 */white-space: nowrap; /* 禁止换行，导致长文本直接溢出容器 */overflow: hidden; /* 只是隐藏了，数据还在，打印时可能看不见 */
}正确写法（弹性宽度 + 强制换行 + 最小宽度）：
/* ✅ 正确示范：自适应 + 安全溢出处理 */
.sign-table {width: 100%;table-layout: fixed; /* 关键：固定表格布局，列宽由第一行或CSS决定，不随内容变 */border-collapse: collapse;
}.sign-table th, .sign-table td {min-width: 50px; /* 保证最小可读性 */max-width: 200px; /* 限制最大宽度，防止单列占满整行 */word-wrap: break-word; /* 长单词强制换行 */word-break: break-all; /* 允许在任意字符处换行（中文天然支持，英文需此属性） */padding: 8px;border: 1px solid #333;vertical-align: top; /* 内容顶部对齐，避免视觉重心偏移 */
}/* 针对特定列的精细控制 */
.col-name {width: 30%; /* 货物名称列占比大一点 */
}
.col-qty {width: 10%; /* 数量列窄一点 */text-align: center;
}代码实战：动态行高与打印优化
在实战项目中，我们不能只依赖 CSS。JavaScript 需要在渲染前对数据做预处理。
这里给出一段通用的 JS 处理逻辑，用于在生成签收单前，清理和格式化数据：
/*** 格式化签收单数据，防止布局崩塌* @param {Array} items 货物列表* @returns {Array} 处理后的安全数据*/
function sanitizeSignItems(items) {return items.map(item = {// 1. 限制名称长度，超长加省略号（数据库存全量，展示截断）const safeName = item.name.length 20 ? item.name.substring(0, 18) + '...' : item.name;// 2. 清理备注中的特殊换行符，统一为 \nconst safeRemark = item.remark.replace(/\r\n/g, '\n').trim();// 3. 确保数量为数字，防止字符串导致的对齐问题const safeQty = parseFloat(item.qty) || 0;return {...item,name: safeName,remark: safeRemark,qty: safeQty};});
}注意：在打印场景下，CSS 的 @media print 必须单独定义。屏幕上的阴影、背景色在打印时会浪费墨粉，甚至导致黑块。
@media print {.sign-container {box-shadow: none !important;padding: 0 !important;margin: 0 !important;background: #fff !important;}.no-print {display: none !important;}/* 确保表格边框清晰 */.sign-table {page-break-inside: auto; /* 允许跨页 */}.sign-table tr {page-break-inside: avoid; /* 禁止行内断页，保持单行完整 */}
}坑二：分页断行，数据被“腰斩”
现象描述
这是最让人崩溃的坑。
你的签收单有20条货物记录。在屏幕上预览时，完美无缺。
点打印，预览窗口显示：第一页正常，第二页也正常。
但是，物理打印出来的纸张上，某一行数据正好卡在页底。结果是：这一行的“货物名称”打印在第一页最底部，而“数量”和“金额”却跑到了第二页的最顶部。
财务看到这种单子，直接拒收。因为数据不完整，无法核对。
根本原因
浏览器的打印引擎在处理分页时，是基于“行高”计算的。
如果一行内容的高度（包括 padding、border）加上当前页剩余空间，小于该行高度，浏览器就会尝试将其推到下一页。
但是，如果这一行内部包含复杂的嵌套结构（比如一个 td 里套了一个 div 再套了一个 span），或者使用了 float、position: absolute，浏览器的计算就会出错。
更隐蔽的原因是：break-inside 属性的兼容性问题。
很多开发只写了 page-break-inside: avoid;，这是旧的 CSS Paged Media 模块属性。虽然 Chrome 和 Edge 支持，但 Safari 和部分企业打印插件可能不识别，或者识别逻辑不一致。
正确写法对比
错误写法（仅依赖旧属性）：
/* ❌ 错误示范：兼容性差，容易失效 */
.sign-table tr {page-break-inside: avoid;
}正确写法（新旧属性共存 + 容器隔离）：
/* ✅ 正确示范：双重保障 + 结构简化 */
.sign-table tr {page-break-inside: avoid; /* 旧属性，兼容部分浏览器 */break-inside: avoid; /* 新标准属性，现代浏览器首选 */
}/* 关键技巧：将每一行视为一个独立的“卡片” */
/* 这样即使行内元素复杂，浏览器也会把整个 tr 当作原子单位处理 */
.sign-table td {position: relative; /* 确保内部绝对定位元素不会跳出 td 边界 */
}/* 针对长备注的特殊处理：如果备注特别长，不要让它独占一行导致行高过高 */
.remark-cell {max-height: 60px; /* 限制备注单元格高度 */overflow: hidden;text-overflow: ellipsis;white-space: nowrap; /* 备注太长时，单行显示，鼠标悬停可看全部 */cursor: help;
}代码实战：手动分页策略
如果项目对打印要求极高（比如法律文书、工程结算单），不要相信浏览器的自动分页。
最稳的方案：前端手动分页。
思路：计算每一行的高度（使用 offsetHeight）。
计算 A4 纸可用高度（考虑页边距）。
累积行高，当超过可用高度时，强制截断，生成第二个 table 或 section。/*** 手动分页逻辑* @param {HTMLElement} container 签收单容器* @param {number} maxPageHeight 单页最大可用高度(px)*/
function manualPagination(container, maxPageHeight = 790) { // A4 210mm * 96dpi/25.4mm ≈ 790px (减去边距)const rows = Array.from(container.querySelectorAll('tr'));const pages = [];let currentRows = [];let currentHeight = 0;// 获取表头高度，每页都需要const headerHeight = container.querySelector('thead').offsetHeight;rows.forEach(row = {const rowHeight = row.offsetHeight;// 如果加上这一行会超过单页限制，且当前页已经有内容了if (currentHeight + rowHeight maxPageHeight currentRows.length 0) {pages.push(currentRows);currentRows = [];currentHeight = 0;}currentRows.push(row);currentHeight += rowHeight;});// 处理剩余行if (currentRows.length 0) {pages.push(currentRows);}// 重新渲染 DOM，为每页生成独立的表格结构// 注意：这里简化了逻辑，实际项目中需要克隆 thead 到每个新表格// 具体实现略，核心是：不要试图让一个 table 跨页，而是生成多个 table// 每个 table 之间加 page-break-after: always;
}为什么推荐手动分页？
因为浏览器自动分页是“黑盒”。你不知道它为什么把第5行断开了。手动分页，你完全掌控每一行去哪一页。在实战项目中，可控性永远优于便利性。
坑三：字体与数字对齐的隐形陷阱
现象描述
签收单里，金额列通常是右对齐。
在开发者的屏幕上，Chrome 浏览器里看，数字排列得非常整齐，小数点对齐，整数位对齐。
发给客户，客户用 Edge 或者 Firefox 打印，发现数字歪歪扭扭，小数点没对齐。
甚至更离谱的情况：同一列里，有的数字是 1,000.00，有的是 1000.00（缺少千分位逗号），导致数字宽度不一致，右对齐后，小数点位置依然参差。
根本原因字体缺失：金额列通常使用等宽字体（Monospace），如 Consolas, Courier New。如果用户系统没有该字体，回退到非等宽字体（如 Arial, Calibri），数字宽度就不一致了。
数据格式不统一：前端直接渲染后端返回的数字。后端返回 1000，前端渲染成 1000；另一条数据返回 1000.5，前端渲染成 1000.5。宽度不同，对齐必乱。正确写法对比
错误写法（依赖系统字体 + 原始数据）：
!-- ❌ 错误示范：字体不可控，数据格式随意 --
td class=amount{{ item.amount }}/td/* 依赖系统默认等宽字体，不同系统差异巨大 */
.amount {font-family: monospace;text-align: right;
}正确写法（强制等宽 + 格式化数据）：
!-- ✅ 正确示范：使用 Web Font 或确保等宽，数据格式化 --
td class=amount{{ formatCurrency(item.amount) }}/td/* 关键：使用特定的等宽字体栈，并设置 tabular-nums */
.amount {font-family: 'SF Mono', 'Consolas', 'Menlo', monospace;font-variant-numeric: tabular-nums; /* 核心：强制数字等宽，即使字体不同 */text-align: right;letter-spacing: 0; /* 消除字间距影响 */
}JavaScript 格式化函数：
/*** 格式化金额，确保固定位数和千分位* @param {number} value 金额* @returns {string} 格式化后的字符串*/
function formatCurrency(value) {if (value === null || value === undefined || isNaN(value)) {return '0.00';}return value.toLocaleString('en-US', {minimumFractionDigits: 2,maximumFractionDigits: 2});
}进阶技巧：使用 ch 单位对齐
如果你无法保证字体加载，可以使用 ch 单位来估算宽度。1ch 等于当前字体中数字 0 的宽度。
.amount-cell {/* 假设最大金额为 9,999,999.99 (13个字符) */width: 13ch;text-align: right;
}虽然这不能保证绝对对齐（如果字体不是严格等宽），但在绝大多数工程字体中，效果足够好。
规避建议与工程化落地
在实战项目中，避免签收单格式问题，不能只靠写代码，要靠流程。建立视觉回归测试
使用 Puppeteer 或 Playwright，在不同分辨率、不同浏览器内核下，截图对比签收单。测试用例：短数据、长数据、特殊字符、空数据、极值数据。
如果截图像素级不一致，CI 流程直接阻断。字体自托管
不要依赖 Google Fonts 或系统字体。将签收单所需的字体文件（Woff2）打包进前端资源，通过 @font-face 引入。确保字体文件体积小，使用 font-display: swap; 防止阻塞渲染。
在 @media print 中，确保字体已加载完成再触发打印。数据层约束
在数据库或 API 层，对签收单的字段长度进行限制。货物名称：VARCHAR(50)
备注：VARCHAR(200)
如果用户输入超长，后端直接报错或截断，不要指望前端 CSS 来救火。打印预览页独立
永远不要让用户在业务操作页直接点打印。
单独做一个 /print/sign/:id 路由。该页面只包含签收单内容，没有任何导航栏、侧边栏、Cookie 提示。
页面加载完成后，自动调用 window.print()（可选，取决于用户体验需求）。
该页面的 CSS 文件独立，不包含全局业务样式，避免污染。参考官方文档
查阅 W3C 的 CSS Paged Media Module Level 3 官方文档。
里面详细定义了 break-before, break-after, break-inside 的行为。
很多开发凭感觉写，结果在不同浏览器表现不一致。读一下规范，能少走很多弯路。总结
签收单格式，看似简单，实则是前端工程中细节决定成败的典型代表。布局：用 table-layout: fixed 和 word-break 解决动态内容撑破问题。
分页：高要求项目用 JS 手动分页，低要求项目用 break-inside: avoid 双保险。
字体：自托管等宽字体，使用 font-variant-numeric: tabular-nums 保证数字对齐。
流程：视觉回归测试 + 数据层约束 + 独立打印页。你在项目里踩过这个坑吗？评论区聊聊，你遇到过最离谱的签收单格式问题是啥？是数字错位，还是分页腰斩？或者字体加载失败导致的乱码？大家互相避避坑。 3个坑坑死实战项目：签收单格式怎么改才不崩
3个坑坑死实战项目：签收单格式怎么改才不崩
版本升级后 API 全变了，你的签收单打印出来全是乱码？别慌，我踩过这个坑。在多个实战项目里，因为签收单格式没对齐，导致财务对账时数据错位，差点背锅。
很多老铁以为签收单就是个简单的 HTML 表格，或者一个 PDF 模板，填填数据就完事了。大错特错。在工程交付、物流流转、甚至内部审批流里，签收单是法律凭证。格式稍微歪一点，字段对不上，后面查账就是灾难。
今天这篇避坑指南，不整虚的。直接上真实项目里的血泪教训。咱们拆解三个最致命的坑：动态字段导致的布局崩塌、打印分页时的断行错乱、字体渲染导致的字符偏移。
读完这篇，你手里的签收单代码，至少能稳过三年。
坑一：动态字段让布局原地爆炸
现象描述
你是不是也遇到过这种情况？在代码里写死了签收单的表格结构，比如“货物名称”、“数量”、“单价”、“总价”。
平时测试数据都是短字符串，看起来挺整齐。结果上线后，客户发来的货物名称长达50个字，或者备注栏里塞了一整段合同条款。
瞬间，表格列宽被撑开，整个签收单变形。原本在一行的“签收人”和“日期”，被挤到了第二行。更可怕的是，如果这是用于打印的，A4纸可能都放不下，变成了两页，第一页只有表头，第二页才是内容。
根本原因
核心问题在于：CSS 布局没有考虑“极端输入”的情况。
很多开发习惯用 table 标签，然后给 td 设置固定的 width。当内容超过这个宽度时，浏览器默认行为是撑开单元格，而不是截断或换行。
另外，很多人喜欢用 flex 布局做签收单，以为这样更现代。但在打印场景下，flex 的表现极不稳定，特别是在不同浏览器（Chrome vs Edge vs Safari）的打印引擎里，计算结果可能不一致。
还有一个隐形杀手：字体加载失败。如果你的签收单用了特殊字体（比如某些工程专用的仿宋），而前端没有配置 @font-face 或者字体文件加载失败，浏览器会回退到默认字体。默认字体的字符宽度与专用字体不同，导致所有列宽计算全部作废。
正确写法对比
错误写法（固定宽度 + 默认换行）：
/* ❌ 错误示范：死板的固定宽度 */
.sign-table td {width: 100px; /* 无论内容多长，都强行占用100px，溢出就撑破 */white-space: nowrap; /* 禁止换行，导致长文本直接溢出容器 */overflow: hidden; /* 只是隐藏了，数据还在，打印时可能看不见 */
}正确写法（弹性宽度 + 强制换行 + 最小宽度）：
/* ✅ 正确示范：自适应 + 安全溢出处理 */
.sign-table {width: 100%;table-layout: fixed; /* 关键：固定表格布局，列宽由第一行或CSS决定，不随内容变 */border-collapse: collapse;
}.sign-table th, .sign-table td {min-width: 50px; /* 保证最小可读性 */max-width: 200px; /* 限制最大宽度，防止单列占满整行 */word-wrap: break-word; /* 长单词强制换行 */word-break: break-all; /* 允许在任意字符处换行（中文天然支持，英文需此属性） */padding: 8px;border: 1px solid #333;vertical-align: top; /* 内容顶部对齐，避免视觉重心偏移 */
}/* 针对特定列的精细控制 */
.col-name {width: 30%; /* 货物名称列占比大一点 */
}
.col-qty {width: 10%; /* 数量列窄一点 */text-align: center;
}代码实战：动态行高与打印优化
在实战项目中，我们不能只依赖 CSS。JavaScript 需要在渲染前对数据做预处理。
这里给出一段通用的 JS 处理逻辑，用于在生成签收单前，清理和格式化数据：
/*** 格式化签收单数据，防止布局崩塌* @param {Array} items 货物列表* @returns {Array} 处理后的安全数据*/
function sanitizeSignItems(items) {return items.map(item = {// 1. 限制名称长度，超长加省略号（数据库存全量，展示截断）const safeName = item.name.length 20 ? item.name.substring(0, 18) + '...' : item.name;// 2. 清理备注中的特殊换行符，统一为 \nconst safeRemark = item.remark.replace(/\r\n/g, '\n').trim();// 3. 确保数量为数字，防止字符串导致的对齐问题const safeQty = parseFloat(item.qty) || 0;return {...item,name: safeName,remark: safeRemark,qty: safeQty};});
}注意：在打印场景下，CSS 的 @media print 必须单独定义。屏幕上的阴影、背景色在打印时会浪费墨粉，甚至导致黑块。
@media print {.sign-container {box-shadow: none !important;padding: 0 !important;margin: 0 !important;background: #fff !important;}.no-print {display: none !important;}/* 确保表格边框清晰 */.sign-table {page-break-inside: auto; /* 允许跨页 */}.sign-table tr {page-break-inside: avoid; /* 禁止行内断页，保持单行完整 */}
}坑二：分页断行，数据被“腰斩”
现象描述
这是最让人崩溃的坑。
你的签收单有20条货物记录。在屏幕上预览时，完美无缺。
点打印，预览窗口显示：第一页正常，第二页也正常。
但是，物理打印出来的纸张上，某一行数据正好卡在页底。结果是：这一行的“货物名称”打印在第一页最底部，而“数量”和“金额”却跑到了第二页的最顶部。
财务看到这种单子，直接拒收。因为数据不完整，无法核对。
根本原因
浏览器的打印引擎在处理分页时，是基于“行高”计算的。
如果一行内容的高度（包括 padding、border）加上当前页剩余空间，小于该行高度，浏览器就会尝试将其推到下一页。
但是，如果这一行内部包含复杂的嵌套结构（比如一个 td 里套了一个 div 再套了一个 span），或者使用了 float、position: absolute，浏览器的计算就会出错。
更隐蔽的原因是：break-inside 属性的兼容性问题。
很多开发只写了 page-break-inside: avoid;，这是旧的 CSS Paged Media 模块属性。虽然 Chrome 和 Edge 支持，但 Safari 和部分企业打印插件可能不识别，或者识别逻辑不一致。
正确写法对比
错误写法（仅依赖旧属性）：
/* ❌ 错误示范：兼容性差，容易失效 */
.sign-table tr {page-break-inside: avoid;
}正确写法（新旧属性共存 + 容器隔离）：
/* ✅ 正确示范：双重保障 + 结构简化 */
.sign-table tr {page-break-inside: avoid; /* 旧属性，兼容部分浏览器 */break-inside: avoid; /* 新标准属性，现代浏览器首选 */
}/* 关键技巧：将每一行视为一个独立的“卡片” */
/* 这样即使行内元素复杂，浏览器也会把整个 tr 当作原子单位处理 */
.sign-table td {position: relative; /* 确保内部绝对定位元素不会跳出 td 边界 */
}/* 针对长备注的特殊处理：如果备注特别长，不要让它独占一行导致行高过高 */
.remark-cell {max-height: 60px; /* 限制备注单元格高度 */overflow: hidden;text-overflow: ellipsis;white-space: nowrap; /* 备注太长时，单行显示，鼠标悬停可看全部 */cursor: help;
}代码实战：手动分页策略
如果项目对打印要求极高（比如法律文书、工程结算单），不要相信浏览器的自动分页。
最稳的方案：前端手动分页。
思路：计算每一行的高度（使用 offsetHeight）。
计算 A4 纸可用高度（考虑页边距）。
累积行高，当超过可用高度时，强制截断，生成第二个 table 或 section。/*** 手动分页逻辑* @param {HTMLElement} container 签收单容器* @param {number} maxPageHeight 单页最大可用高度(px)*/
function manualPagination(container, maxPageHeight = 790) { // A4 210mm * 96dpi/25.4mm ≈ 790px (减去边距)const rows = Array.from(container.querySelectorAll('tr'));const pages = [];let currentRows = [];let currentHeight = 0;// 获取表头高度，每页都需要const headerHeight = container.querySelector('thead').offsetHeight;rows.forEach(row = {const rowHeight = row.offsetHeight;// 如果加上这一行会超过单页限制，且当前页已经有内容了if (currentHeight + rowHeight maxPageHeight currentRows.length 0) {pages.push(currentRows);currentRows = [];currentHeight = 0;}currentRows.push(row);currentHeight += rowHeight;});// 处理剩余行if (currentRows.length 0) {pages.push(currentRows);}// 重新渲染 DOM，为每页生成独立的表格结构// 注意：这里简化了逻辑，实际项目中需要克隆 thead 到每个新表格// 具体实现略，核心是：不要试图让一个 table 跨页，而是生成多个 table// 每个 table 之间加 page-break-after: always;
}为什么推荐手动分页？
因为浏览器自动分页是“黑盒”。你不知道它为什么把第5行断开了。手动分页，你完全掌控每一行去哪一页。在实战项目中，可控性永远优于便利性。
坑三：字体与数字对齐的隐形陷阱
现象描述
签收单里，金额列通常是右对齐。
在开发者的屏幕上，Chrome 浏览器里看，数字排列得非常整齐，小数点对齐，整数位对齐。
发给客户，客户用 Edge 或者 Firefox 打印，发现数字歪歪扭扭，小数点没对齐。
甚至更离谱的情况：同一列里，有的数字是 1,000.00，有的是 1000.00（缺少千分位逗号），导致数字宽度不一致，右对齐后，小数点位置依然参差。
根本原因字体缺失：金额列通常使用等宽字体（Monospace），如 Consolas, Courier New。如果用户系统没有该字体，回退到非等宽字体（如 Arial, Calibri），数字宽度就不一致了。
数据格式不统一：前端直接渲染后端返回的数字。后端返回 1000，前端渲染成 1000；另一条数据返回 1000.5，前端渲染成 1000.5。宽度不同，对齐必乱。正确写法对比
错误写法（依赖系统字体 + 原始数据）：
!-- ❌ 错误示范：字体不可控，数据格式随意 --
td class=amount{{ item.amount }}/td/* 依赖系统默认等宽字体，不同系统差异巨大 */
.amount {font-family: monospace;text-align: right;
}正确写法（强制等宽 + 格式化数据）：
!-- ✅ 正确示范：使用 Web Font 或确保等宽，数据格式化 --
td class=amount{{ formatCurrency(item.amount) }}/td/* 关键：使用特定的等宽字体栈，并设置 tabular-nums */
.amount {font-family: 'SF Mono', 'Consolas', 'Menlo', monospace;font-variant-numeric: tabular-nums; /* 核心：强制数字等宽，即使字体不同 */text-align: right;letter-spacing: 0; /* 消除字间距影响 */
}JavaScript 格式化函数：
/*** 格式化金额，确保固定位数和千分位* @param {number} value 金额* @returns {string} 格式化后的字符串*/
function formatCurrency(value) {if (value === null || value === undefined || isNaN(value)) {return '0.00';}return value.toLocaleString('en-US', {minimumFractionDigits: 2,maximumFractionDigits: 2});
}进阶技巧：使用 ch 单位对齐
如果你无法保证字体加载，可以使用 ch 单位来估算宽度。1ch 等于当前字体中数字 0 的宽度。
.amount-cell {/* 假设最大金额为 9,999,999.99 (13个字符) */width: 13ch;text-align: right;
}虽然这不能保证绝对对齐（如果字体不是严格等宽），但在绝大多数工程字体中，效果足够好。
规避建议与工程化落地
在实战项目中，避免签收单格式问题，不能只靠写代码，要靠流程。建立视觉回归测试
使用 Puppeteer 或 Playwright，在不同分辨率、不同浏览器内核下，截图对比签收单。测试用例：短数据、长数据、特殊字符、空数据、极值数据。
如果截图像素级不一致，CI 流程直接阻断。字体自托管
不要依赖 Google Fonts 或系统字体。将签收单所需的字体文件（Woff2）打包进前端资源，通过 @font-face 引入。确保字体文件体积小，使用 font-display: swap; 防止阻塞渲染。
在 @media print 中，确保字体已加载完成再触发打印。数据层约束
在数据库或 API 层，对签收单的字段长度进行限制。货物名称：VARCHAR(50)
备注：VARCHAR(200)
如果用户输入超长，后端直接报错或截断，不要指望前端 CSS 来救火。打印预览页独立
永远不要让用户在业务操作页直接点打印。
单独做一个 /print/sign/:id 路由。该页面只包含签收单内容，没有任何导航栏、侧边栏、Cookie 提示。
页面加载完成后，自动调用 window.print()（可选，取决于用户体验需求）。
该页面的 CSS 文件独立，不包含全局业务样式，避免污染。参考官方文档
查阅 W3C 的 CSS Paged Media Module Level 3 官方文档。
里面详细定义了 break-before, break-after, break-inside 的行为。
很多开发凭感觉写，结果在不同浏览器表现不一致。读一下规范，能少走很多弯路。总结
签收单格式，看似简单，实则是前端工程中细节决定成败的典型代表。布局：用 table-layout: fixed 和 word-break 解决动态内容撑破问题。
分页：高要求项目用 JS 手动分页，低要求项目用 break-inside: avoid 双保险。
字体：自托管等宽字体，使用 font-variant-numeric: tabular-nums 保证数字对齐。
流程：视觉回归测试 + 数据层约束 + 独立打印页。你在项目里踩过这个坑吗？评论区聊聊，你遇到过最离谱的签收单格式问题是啥？是数字错位，还是分页腰斩？或者字体加载失败导致的乱码？大家互相避避坑。