合同电子签名需后端解析或PDF渲染库支持，前端仅上传文件不够；签名坐标须绑定PDF绝对坐标系；合并必须服务端完成；法律效力依赖哈希、时间戳与身份绑定。
合同文件上传必须用 <input type="file">，但仅上传远远不够
浏览器原生不支持直接在 PDF 或 Word 文件上绘图签字，<input type="file"> 只能完成第一步：把合同文件（通常是 .pdf）传到服务器。常见错误是以为上传后前端就能“打开 PDF 签字”，实际上浏览器无法原生渲染可编辑的 PDF 签章界面。必须配合后端解析（如用 pdf-lib、Apache PDFBox）或前端 PDF 渲染库（如 pdfjs-dist + 画布叠加）才能继续。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 限制上传类型：
accept=".pdf"，避免用户选中 Word 或图片导致后续流程断裂 - 服务端需校验
Content-Type和文件头（如 PDF 的%PDF-），防止伪造扩展名绕过 - 上传后立即返回唯一
fileId（非文件路径），供后续签字操作关联，别直接暴露服务器路径
前端签字区域不能靠 <canvas> 自己画完就完事
单纯用 <canvas> 捕获鼠标/触控轨迹生成签名图，只是“画了一张图”，和合同原文毫无结构关联。下次打开时，这张图不会自动对齐到合同第 3 页底部——位置、缩放、页码都会错乱。真正可用的方案必须将签名坐标绑定到 PDF 页面的绝对坐标系（单位：点，1/72 英寸）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
pdfjs-dist加载 PDF，调用getPage()获取页面view尺寸，再将 canvas 坐标按比例映射到 PDF 坐标 - 签名数据至少保存：页码、x/y 偏移（PDF 坐标）、缩放系数、笔迹路径数组（不是图片 base64）
- 移动端需监听
touchstart/touchmove，禁用touch-action: none防止手势冲突
签字后合并 PDF 必须在服务端做，前端 pdf-lib 不可靠
前端用 pdf-lib 虽能插入图像或文本签章，但存在严重限制：不支持字体嵌入（中文常变方块）、无法处理加密 PDF、多页大文件易内存溢出。生产环境必须交由服务端完成最终合成。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 前端只提交签名元数据（页码、坐标、路径点），服务端用
pdf-lib（Node.js）或pdfbox（Java）加载原始 PDF，按坐标绘制矢量签名路径或嵌入 PNG 签章图 - 签章图推荐用透明 PNG + 300dpi，避免缩放模糊；矢量路径更小但兼容性略差
- 合成后务必用
qpdf --check验证 PDF 结构有效性，部分 PDF 查看器对损坏结构极其敏感
法律效力关键在时间戳与哈希，不是“看起来像签字”
用户看到红手写体+日期就以为有效？司法实践中，电子签名有效性核心是“不可否认性”。没时间戳、没原文哈希、没签署人身份绑定，这份合同连基础证据链都不完整。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 服务端签署前计算原始 PDF 的
sha256，连同timestamp、userId一起存入数据库 - 使用可信时间戳服务（如国家授时中心 API）或自建 NTP 同步服务器，避免本地时间被篡改
- 最终输出 PDF 应嵌入数字签名（
adbe.pkcs7.detached），而非仅视觉签章——这需要 PKI 体系支持，中小项目常被忽略
真正的难点不在“怎么画一笔”，而在确保这一笔和原始文件、签署人、时间强绑定。跳过哈希校验和时间戳，等于签字后立刻失去法律支撑点。
