电子合同骑缝章必须由服务端调用可信签名sdk（如腾讯电子签api）进行数字签名并嵌入pdf图层，确保每页内容与印章强绑定；前端仅上传原始pdf并轮询状态，严禁前端盖章或破坏pdf结构。
电子合同上传时怎么保证文件不被篡改
骑缝章不是简单盖个图，核心是让合同每页内容和印章形成强绑定。直接在前端用 canvas 或 img 盖章只是视觉伪造，后端没参与签名，法律效力为零。真正可行的路径只有一条：上传原始 PDF 后，由服务端调用可信签名 SDK（如 eSign、CFCA、腾讯电子签 API）做数字签名+骑缝章渲染。
常见错误是前端把 PDF 拆成图片再拼接盖章——这破坏了 PDF 的文本可选性、搜索性和数字签名结构，也过不了等保和司法鉴定要求。
- 必须保留原始 PDF 的结构和元数据，骑缝章要作为不可剥离的 PDF 图层嵌入（不是浮层）
- 所有签名操作必须在服务端完成，私钥绝不接触前端
- 上传接口需校验
Content-Type: application/pdf和文件头（%PDF-1.），拒绝任何伪装成 PDF 的 HTML 或 ZIP
服务端生成骑缝章 PDF 的关键参数
调用 PDF 签名 SDK 时，sealPosition 和 pageRange 这两个参数决定骑缝效果是否合法。骑缝章不是每页盖一个章，而是跨页连续覆盖（例如章体横跨第 3 页右下角 + 第 4 页左下角）。
以 iText7 + 国密 SM2 签名为例：
pdfSigner.setSignatureAppearance(pdfStamper, "signatureField", 3, 4);
pdfSigner.setSealImage(sealImage); // 骑缝章必须是带透明通道的 PNG
pdfSigner.setSealOffsetX(-20); // 负值才能让章体向左溢出到前一页
pdfSigner.setPageRange(new int[]{3, 4}); // 明确限定仅作用于这两页边界
-
setSealOffsetX为负值才可能实现“缝合”，正值只会把章盖歪在单页内 - 国密合规场景下，必须用
SM2ParameterSpec替代默认 RSA，否则签名不被司法采信 - 骑缝章图像尺寸建议 ≥ 300×150px，DPI 不低于 300，否则打印放大后模糊
前端上传如何配合后端签名流程
用户上传合同 PDF 后，前端不能直接显示“已盖章”，而应进入状态轮询。因为签名是异步耗时操作（尤其要调用硬件加密机时），且涉及时间戳服务器（TSA）授时。
- 上传成功后，后端返回
signTaskId，前端用它轮询/api/sign/status?taskId=xxx - 响应中必须包含
timestamp（TSA 返回的权威时间）和digest（原文 SHA256 值），供前端校验一致性 - 禁止用
location.href跳转下载，应通过fetch+blob触发下载，避免 URL 泄露signTaskId - 若轮询超时（建议 90s），前端提示“签名系统繁忙，请稍后查收邮件”，而非报错重试
为什么不能用前端 JS 库直接盖骑缝章
像 pdf-lib 或 jsPDF 确实能往 PDF 插入图像，但它们无法完成法律意义上的“电子签名”：没有私钥运算、不生成符合《电子签名法》第十三条的可靠电子签名、不接入 TSA 时间戳、不写入 DocMDP 权限字段锁定文档编辑。
更隐蔽的问题是：这些库生成的 PDF 在 Adobe Acrobat 中会显示“签名无效”或“文档已被更改”，因为它们修改了 PDF 的交叉引用表（xref）却未重新计算签名摘要。
- 即使你用
pdf-lib强行插入骑缝图层，Acrobat 会检测到ByteRange不匹配而标红警告 - 法院采信的电子合同必须通过 Adobe 的“签名验证”面板，显示绿色对勾和“该签名是可信的”
- 所有纯前端方案都绕不开私钥落地风险——一旦私钥被提取，整套签名体系即失效
骑缝章的物理逻辑是“一纸两页共压一印”，技术实现上必须让签名行为同时锚定相邻页面的内容哈希，这个动作只能由具备密钥管理和 TSA 对接能力的服务端完成。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
