企业官网建设流程全解析

群里一聊网页打印，两条线老被揉成一团：

服务器挂个 Puppeteer，page.pdf()很爽；
仓库又说要「静默打到那台热敏机」。

前者产物是文件，后者产物是纸。机房里的无头浏览器，够不着柜台 USB 口——这不是框架缺陷，是空间问题。

我怎么分

要电子底稿、邮件附件、统一字体归档 → 继续 Puppeteer / 别的 PDF 管线，别为了「打印」两个字硬上桌面客户端。

要指定门店打印机、少弹窗、人还在工位旁边 → 本机打印客户端。页面用web-print-pdf触发，Web打印专家出纸。

两个都要也很常见：服务端先出 PDF 归档，工位再拿 URL 打：

npminstallweb-print-pdf

importwebPrintPdffrom'web-print-pdf'// 浏览器里，把已签发的 PDF 送到本机打印机awaitwebPrintPdf.printPdfByUrl(pdfUrl,{},{printerName:'仓内面单机',copies:1},{action:'print'})

HTML 直打也行，适合小票这种本来就网页排版的东西：

awaitwebPrintPdf.printHtml(html,{paperFormat:'A4'},{printerName:'仓内面单机'})

别把web-print-pdf丢进 Node 服务里跑——它认的是用户桌面上的客户端，不是你的 K8s Pod。

我见过的委屈架构

只在服务器堆 PDF，业务同学下载再手动打：能交差，高峰等于没有自动化。
以为 npm 包装上服务器就能「云直打门店」：门店机器不在链路里，直打不成立。
只追求静默、不留底稿：纸丢了、纠纷来了，库里什么都没有，更难受。出纸成功顺便留 PDF，或先 PDF 再打，看你们合规要求。

成本直觉

Puppeteer 贵在服务器 CPU 内存和队列；本地静默把麻烦摊到工位安装与自启。上千门店若要云端直达每台设备，那是另一类云打印产品；多数业务系统用「工位客户端」更现实。

收束

Puppeteer 解决「生成文档」，工位静默解决「这台柜出台纸」。可以串，不要并成一个 API 幻想。选型时先问自己要的是文件还是纸，答案清楚了工具就清楚了。

包名：web-print-pdf。不放外链。