后台系统做到一定阶段打印一定会变成最脏的活。业务最初说能打印就行上线三个月后需求变成表头要在每页重复、这张单要套打、批量打 200 张、不要弹框、能不能让业务自己改模板。等你把这些都补上代码里已经堆了三千行排版逻辑还没人敢动。问题往往不在实现而在第一步方案选错了。项目地址https://gitee.com/theGreatOldFive/vue-print-designer一、四条路线的本质区别先说结论这四条路线的差异不在能不能打出纸而在排版逻辑放在哪、模板归谁维护。配图1四条打印路线的取舍路线排版在哪分页谁控制模板谁维护典型接入成本window.print浏览器排版引擎CSS前端0.5-2 人天html2canvas jsPDF前端 canvas手动切片前端2-5 人天Puppeteer服务端 Chromium引擎控制前端 后端5-10 人天模板设计器渲染引擎模板内置业务自己3-8 人天成本不在开发在变更。前三条路线业务每改一次版式都要走一遍需求 → 开发 → 测试 → 发版第四条只改配置。一年改 10 次模板前三条累计要吃掉 20-40 人天。二、window.print能走多远最短路径也是最适合内部单据的一条。media print { page { size: A4; margin: 12mm 10mm; } /* 表头每页重复 */ thead { display: table-header-group; } /* 行不要被劈开 */ tr { break-inside: avoid; page-break-inside: avoid; } /* 交互元素不打印 */ .no-print, .toolbar, .pagination { display: none !important; } }它的边界很清楚必须弹打印对话框用户要自己选打印机、点确认边距受浏览器影响不同浏览器默认页边距不一致套打基本不可行毫米级定位会被浏览器默认边距吃掉静默打印做不到这是浏览器安全模型决定的。所以它适合内部审批单、对账单、报表——用户点一下、选打印机、确认这个流程可以接受。如果业务只是把页面打出来这条路能覆盖 60% 的需求别过度设计。三、截图方案一页以内才划算用户要的不是打印而是下载一个 PDF 文件时html2canvas jsPDF 最快。import html2canvas from html2canvas import { jsPDF } from jspdf async function exportPdf(el, filename) { const canvas await html2canvas(el, { scale: 2, // 关键至少 2 倍否则模糊 useCORS: true, // 跨域图片 backgroundColor: #ffffff, logging: false, }) const pdf new jsPDF(p, mm, a4) const pageW 210 const imgH (canvas.height * pageW) / canvas.width pdf.addImage(canvas.toDataURL(image/jpeg, 0.95), JPEG, 0, 0, pageW, imgH) pdf.save(filename) }三个硬伤必须提前知道文字变成图片不可搜索、不可复制、放大就糊长内容撞 canvas 上限Chrome 单边最大 32767px几十页的报告直接崩切页会把字劈成两半因为它是按图片高度硬切不认行边界。结论一页以内能用超过两页就该换路。它最适合电子回单、短凭证这类打完就存档、不会二次编辑的场景。四、服务端渲染最准也最重Puppeteer 出 PDF 的好处是分页、页码、页眉页脚全部交给 Chromium 的排版引擎const browser await puppeteer.launch({ args: [--no-sandbox] }) const page await browser.newPage() await page.setContent(html, { waitUntil: networkidle0 }) await page.evaluate(() document.fonts.ready) await page.pdf({ path: out.pdf, format: A4, printBackground: true, displayHeaderFooter: true, headerTemplate: div stylefont-size:9px;width:100%;text-align:center合同编号 {{no}}/div, footerTemplate: div stylefont-size:9px;width:100%;text-align:center 第 span classpageNumber/span / span classtotalPages/span 页/div, }) await browser.close()代价也很实在服务器要装 Chromium镜像 400MB 起步并发高时内存吃紧一台 2C4G 的机器同时跑 5 个渲染任务就开始排队前端还要额外维护一套给后端用的 HTML和页面样式容易漂移调试链路长改一个像素要重新部署才能看到。适合医院报告、检验单、对账单这类必须归档、分页严格的场景。五、模板设计器把排版从代码里拿出来前三条路线的共同点是模板写死在代码里。业务想加一列规格、换一下公司抬头、把表头字体改大都要提需求、排期、发版、回归测试。一个中型 ERP这类需求一年能有几十条。模板设计器的思路是把排版抽出来业务在页面上拖字段、设字号、画表格线导出 JSON渲染时用同一套引擎填数据、算分页、出纸。{ schemaVersion: 3, paper: { width: 210, height: 297, unit: mm }, bands: [ { type: pageHeader, height: 25, repeat: true }, { type: detail, height: 8, repeat: true, source: items }, { type: summary, height: 40, repeat: false } ], elements: [ { type: text, x: 10, y: 8, w: 80, h: 8, binding: title }, { type: barcode, x: 8, y: 220, w: 84, h: 20, binding: orderNo } ] }关键要求只有一条设计态和打印态共用一套渲染。如果设计器用一套 DOM、打印用另一套设计稿和成品永远差两毫米用户会觉得这工具不靠谱。配图2模板市场里现成的单据模板这套结构我参考的是 vue-print-designer 的实现模板 JSON 统一渲染器 带band分页三块都开源优点是可以照着它的字段设计自己复刻一个渲染器不用担心被锁死。六、六个维度横向对比维度window.print截图方案Puppeteer模板设计器输出质量矢量位图矢量矢量分页可控性中靠 CSS差高高静默打印不支持不支持需配合客户端需配合客户端套打精度低低中高mm 定位模板维护前端前端前端后端业务自助运维成本无低高Chromium低七、选型决策流程按顺序问四个问题问完基本就定了模板一年改几次0-2 次 → 走前三条5 次以上 → 直接看设计器。内容会不会超过一页会 → 排除截图方案。要不要归档 PDF要 → 服务端渲染或设计器渲染。有没有套打/标签有 → 必须能控制毫米级坐标前两条直接排除。四个问题里只要有一个落在设计器那侧就说明你的系统已经进入打印是长期成本的阶段了。八、从 window.print 迁移到设计器的路径很多团队不是从零开始而是已经有一堆media print的样式。迁移可以分三步不用推倒重来第一步把版式数据化。把现在写死的表格列、字段抽成一份配置先不用做成可视化设计器。第二步统一渲染入口。所有打印走同一个PrintRenderer :template :data先只支持配置渲染不支持拖拽编辑。第三步接设计器。业务方开始自己改模板前端只维护渲染器。这三步每步都能独立上线风险可控。跳过前两步直接上设计器通常会在老模板怎么兼容上卡住。九、几个容易忽略的细节纸张尺寸必须在打印机驱动里建好否则会回退到 A4 并缩放套打全废打印缩放必须 100%浏览器适应纸张会破坏毫米级布局字体要随应用分发别赌用户机器装了什么page { margin: 0 }之后要自己用 padding 撑内容区否则内容贴着纸边条码一律 SVG位图在 203dpi 下会糊。配图3热敏小票——最常见的打印形态之一十、一张决策表收尾你的处境选它理由内部审批单模板不改window.print半天干完别过度设计要下载 PDF一页内html2canvas jsPDF前端自足不用服务端必须归档分页严格Puppeteer分页页码最稳模板由业务维护模板设计器改版式不发版既要套打又要多联设计器 mm 定位手写坐标维护不动选型的关键不是技术先进而是你愿意为模板变更付多少成本。前期省下的接入时间后期会以排期的形式还回去。
后台系统做到一定阶段打印一定会变成最脏的活。业务最初说能打印就行上线三个月后需求变成表头要在每页重复、这张单要套打、批量打 200 张、不要弹框、能不能让业务自己改模板。等你把这些都补上代码里已经堆了三千行排版逻辑还没人敢动。问题往往不在实现而在第一步方案选错了。项目地址https://gitee.com/theGreatOldFive/vue-print-designer一、四条路线的本质区别先说结论这四条路线的差异不在能不能打出纸而在排版逻辑放在哪、模板归谁维护。配图1四条打印路线的取舍路线排版在哪分页谁控制模板谁维护典型接入成本window.print浏览器排版引擎CSS前端0.5-2 人天html2canvas jsPDF前端 canvas手动切片前端2-5 人天Puppeteer服务端 Chromium引擎控制前端 后端5-10 人天模板设计器渲染引擎模板内置业务自己3-8 人天成本不在开发在变更。前三条路线业务每改一次版式都要走一遍需求 → 开发 → 测试 → 发版第四条只改配置。一年改 10 次模板前三条累计要吃掉 20-40 人天。二、window.print能走多远最短路径也是最适合内部单据的一条。media print { page { size: A4; margin: 12mm 10mm; } /* 表头每页重复 */ thead { display: table-header-group; } /* 行不要被劈开 */ tr { break-inside: avoid; page-break-inside: avoid; } /* 交互元素不打印 */ .no-print, .toolbar, .pagination { display: none !important; } }它的边界很清楚必须弹打印对话框用户要自己选打印机、点确认边距受浏览器影响不同浏览器默认页边距不一致套打基本不可行毫米级定位会被浏览器默认边距吃掉静默打印做不到这是浏览器安全模型决定的。所以它适合内部审批单、对账单、报表——用户点一下、选打印机、确认这个流程可以接受。如果业务只是把页面打出来这条路能覆盖 60% 的需求别过度设计。三、截图方案一页以内才划算用户要的不是打印而是下载一个 PDF 文件时html2canvas jsPDF 最快。import html2canvas from html2canvas import { jsPDF } from jspdf async function exportPdf(el, filename) { const canvas await html2canvas(el, { scale: 2, // 关键至少 2 倍否则模糊 useCORS: true, // 跨域图片 backgroundColor: #ffffff, logging: false, }) const pdf new jsPDF(p, mm, a4) const pageW 210 const imgH (canvas.height * pageW) / canvas.width pdf.addImage(canvas.toDataURL(image/jpeg, 0.95), JPEG, 0, 0, pageW, imgH) pdf.save(filename) }三个硬伤必须提前知道文字变成图片不可搜索、不可复制、放大就糊长内容撞 canvas 上限Chrome 单边最大 32767px几十页的报告直接崩切页会把字劈成两半因为它是按图片高度硬切不认行边界。结论一页以内能用超过两页就该换路。它最适合电子回单、短凭证这类打完就存档、不会二次编辑的场景。四、服务端渲染最准也最重Puppeteer 出 PDF 的好处是分页、页码、页眉页脚全部交给 Chromium 的排版引擎const browser await puppeteer.launch({ args: [--no-sandbox] }) const page await browser.newPage() await page.setContent(html, { waitUntil: networkidle0 }) await page.evaluate(() document.fonts.ready) await page.pdf({ path: out.pdf, format: A4, printBackground: true, displayHeaderFooter: true, headerTemplate: div stylefont-size:9px;width:100%;text-align:center合同编号 {{no}}/div, footerTemplate: div stylefont-size:9px;width:100%;text-align:center 第 span classpageNumber/span / span classtotalPages/span 页/div, }) await browser.close()代价也很实在服务器要装 Chromium镜像 400MB 起步并发高时内存吃紧一台 2C4G 的机器同时跑 5 个渲染任务就开始排队前端还要额外维护一套给后端用的 HTML和页面样式容易漂移调试链路长改一个像素要重新部署才能看到。适合医院报告、检验单、对账单这类必须归档、分页严格的场景。五、模板设计器把排版从代码里拿出来前三条路线的共同点是模板写死在代码里。业务想加一列规格、换一下公司抬头、把表头字体改大都要提需求、排期、发版、回归测试。一个中型 ERP这类需求一年能有几十条。模板设计器的思路是把排版抽出来业务在页面上拖字段、设字号、画表格线导出 JSON渲染时用同一套引擎填数据、算分页、出纸。{ schemaVersion: 3, paper: { width: 210, height: 297, unit: mm }, bands: [ { type: pageHeader, height: 25, repeat: true }, { type: detail, height: 8, repeat: true, source: items }, { type: summary, height: 40, repeat: false } ], elements: [ { type: text, x: 10, y: 8, w: 80, h: 8, binding: title }, { type: barcode, x: 8, y: 220, w: 84, h: 20, binding: orderNo } ] }关键要求只有一条设计态和打印态共用一套渲染。如果设计器用一套 DOM、打印用另一套设计稿和成品永远差两毫米用户会觉得这工具不靠谱。配图2模板市场里现成的单据模板这套结构我参考的是 vue-print-designer 的实现模板 JSON 统一渲染器 带band分页三块都开源优点是可以照着它的字段设计自己复刻一个渲染器不用担心被锁死。六、六个维度横向对比维度window.print截图方案Puppeteer模板设计器输出质量矢量位图矢量矢量分页可控性中靠 CSS差高高静默打印不支持不支持需配合客户端需配合客户端套打精度低低中高mm 定位模板维护前端前端前端后端业务自助运维成本无低高Chromium低七、选型决策流程按顺序问四个问题问完基本就定了模板一年改几次0-2 次 → 走前三条5 次以上 → 直接看设计器。内容会不会超过一页会 → 排除截图方案。要不要归档 PDF要 → 服务端渲染或设计器渲染。有没有套打/标签有 → 必须能控制毫米级坐标前两条直接排除。四个问题里只要有一个落在设计器那侧就说明你的系统已经进入打印是长期成本的阶段了。八、从 window.print 迁移到设计器的路径很多团队不是从零开始而是已经有一堆media print的样式。迁移可以分三步不用推倒重来第一步把版式数据化。把现在写死的表格列、字段抽成一份配置先不用做成可视化设计器。第二步统一渲染入口。所有打印走同一个PrintRenderer :template :data先只支持配置渲染不支持拖拽编辑。第三步接设计器。业务方开始自己改模板前端只维护渲染器。这三步每步都能独立上线风险可控。跳过前两步直接上设计器通常会在老模板怎么兼容上卡住。九、几个容易忽略的细节纸张尺寸必须在打印机驱动里建好否则会回退到 A4 并缩放套打全废打印缩放必须 100%浏览器适应纸张会破坏毫米级布局字体要随应用分发别赌用户机器装了什么page { margin: 0 }之后要自己用 padding 撑内容区否则内容贴着纸边条码一律 SVG位图在 203dpi 下会糊。配图3热敏小票——最常见的打印形态之一十、一张决策表收尾你的处境选它理由内部审批单模板不改window.print半天干完别过度设计要下载 PDF一页内html2canvas jsPDF前端自足不用服务端必须归档分页严格Puppeteer分页页码最稳模板由业务维护模板设计器改版式不发版既要套打又要多联设计器 mm 定位手写坐标维护不动选型的关键不是技术先进而是你愿意为模板变更付多少成本。前期省下的接入时间后期会以排期的形式还回去。
