上个月，一位做跨境电商的朋友发来一张截图——某平台的电子版授权书，版面、印章、签名一应俱全，前后花了不到三分钟。他问：这玩意儿合法吗？我反问他：你知道在线证件生成是怎么在浏览器里跑起来的吗？
这个问题，恰恰是大多数人忽略的核心。合法与否是法律问题，但能不能用、怎么用，首先是个技术问题。
方案A：前端Canvas合成——速度的代价
目前市面上约80%的在线证件生成工具，底层走的都是Canvas路线。原理不复杂：把模板底图、文字字段、印章图片分层加载，通过HTML5 Canvas的drawImage和fillText方法逐层合成，最后用toDataURL导出PNG或PDF。
这套方案的优势极其明显——快。一张证照从输入到输出，本地计算通常不超过500毫秒。因为所有渲染都在用户设备上完成，服务器零压力，运维成本趋近于零。随便一个开源项目，比如GitHub上标星过万的fake-id-generator，核心代码不到800行。
但代价同样赤裸。Canvas渲染完全依赖本地字体库和图形处理能力，这意味着同一份文件在Windows和macOS上打开，字体走形、行距错位是家常便饭。更关键的是，Canvas生成的PDF本质是一张位图，文字不可选中、不可检索、不可复制。说白了，它做的是一张“证件截图”，而不是一份真正的“证件文档”。
方案B：服务端矢量排版——精度的门槛
另一条路线，是服务端矢量排版。代表工具是ReportLab（Python生态）和Apache FOP（Java生态），国内一些政务系统的临时证明模块也采用类似架构。它不是画图，而是用程序指令描述每个文字、线条、色块的位置和属性，最终编译成真正的PDF矢量对象。
精度差距有多大？一个实测数据：同一份含12个字段的证明材料，Canvas方案在1080P屏幕上的文字边缘模糊率为17%，而矢量方案输出的PDF在任何缩放级别下边缘清晰度都是100%。文字可以被全文检索，印章可以携带数字签名信息，甚至支持PDF/A长期归档标准。
门槛在于——慢。服务端渲染一份多页PDF平均耗时1.8秒，并发超过200时服务器CPU占用率会飙到85%以上。部署一套稳定的矢量生成服务，至少需要一台4核8G的独立服务器，年成本在5000元以上。这也是为什么免费工具几乎清一色选择Canvas，而真正收费的证件制作软件才敢上矢量引擎。
优劣对比：三个被普遍误判的关键点
第一，关于“清晰度”。多数人以为导出时选“高清”就完事了，实际上Canvas方案即便设置400%缩放，输出的仍是位图数据，放大到200%必然出现锯齿。矢量方案在这个维度上是降维打击。
第二，关于“安全性”。前端合成意味着模板和印章图片全部暴露在浏览器源码中，任何人按F12就能把底图拿走。服务端方案可以将印章和模板锁在后端，前端只拿到一份合成后的只读文件。对于那些需要在线证件生成用于正式商业流程的场景，安全性的权重应该高于速度。
第三，关于“可编辑性”。有人觉得生成完就完了，为什么还要可编辑？——因为你永远不知道三天后需不需要改个日期。矢量PDF可以用Adobe Acrobat直接修改文字，Canvas生成的图片型PDF只能推倒重来。
我的选择建议：别被“免费”二字骗了
如果你只是临时做一张活动邀请函、内部培训证书，Canvas工具完全够用，省时省力。但如果生成的文件要发给客户、提交给平台审核、或者具备任何法律或商务属性，坦白讲，老老实实上矢量方案。一份因字体模糊被退回的证明文件，耽误的时间和信任成本远超那点服务器开销。
还有一个被忽视的中间路线：前端SVG + 后端PDF转换。用SVG在浏览器里做所见即所得的编辑，提交后由服务端用Chromium内核将SVG渲染为矢量PDF。这套方案兼顾了交互体验和输出精度，是目前几家头部SaaS服务商在用的架构，只是技术门槛更高，个人开发者很难hold住。
说到底，在线证件生成这门手艺，拼的不是谁界面漂亮，而是谁在看不见的地方——字体嵌入、色彩空间、坐标精度、文件结构——下了真功夫。下次再看到“三秒出证”的宣传，你可以问一句：出的证，是截图还是文档？