简介这套H5横屏签名源码基于jSignature插件实现完整可直接运行面向Web前端开发者与需要快速接入电子签名功能的项目团队重点解决手机横屏状态下手写签名采集、实时回显与图片导出等问题。资源包共69个文件压缩后仅2.98MB主要包括27个js交互脚本、15个css样式文件以及字体、图标、示例页面等配套素材目录结构清晰便于按模块引用或二次开发目前已有1073人学习下载。代码内含jSignature核心插件、jQuery依赖及完整的横屏签名页面运行后可直接在手机上横屏书写并保存为指定格式的签名图片图片格式可自由选择同时附带了相关样式与示例文档方便快速理解调用逻辑。无论是直接部署到业务系统还是参考其横屏布局与签名生成思路进行定制这套资源都能为签名功能开发节省大量从零搭建的时间。1. 移动端签名板选型为什么我最终留下了 jSignature 这套横屏源码H5 页面里做电子签名最容易翻车的不是签名本身而是横屏。很多从业者第一次拿到需求时都很乐观竖屏弹层画个 canvas 不就行了吗真放到手机上一测就露馅——银行开户、保险确认、物业签收这类场景几乎全是横屏表单页面得旋转 90 度canvas 坐标跟着错位手指落笔位置和笔迹偏移能差出半个签名区。这套基于 jSignature 的 H5 签名横屏源码解决的就是这个痛点它把 jSignature 封装进了一个横屏容器里直接运行就能看到签名板旋转、缩放、坐标校正后的真实效果拿到业务里改改接口参数就能用。源码包的完整度对得起“可直接运行”这几个字不依赖特定框架原生 H5 引入 jSignature 库就能跑配了完整的横屏样式和初始化逻辑。适合三类人一是急着交差的业务前端需要一份能跑通的参考实现二是做移动端表单类项目、想了解横屏 canvas 坐标问题怎么处理的开发者三是带外包团队、需要快速验证技术方案的负责人。下面从横屏方案、初始化配置、业务功能封装到真实设备避坑一条线拆完。2. 横屏签名板先解决画布旋转再谈笔迹采集2.1 竖屏转横屏的两种实现路径对比H5 里做横屏主流做法无非两种CSS transform 旋转整个页面或者依赖原生 API 强制横屏。先说结论这套源码选的是前者因为后者的兼容性坑太多——安卓碎片化严重微信内置浏览器对强制横屏的 API 支持不统一iOS 上 Safari 对旋转 API 的响应时好时坏线上环境出了问题你连复现都得看用户手机型号脸色。CSS transform 方案的思路是把整个应用容器旋转 90 度再用视口宽高换算补偿旋转后的布局尺寸。核心就三行样式.app-canvas-wrapper { position: fixed; top: 0; left: 0; width: 100vh; /* 旋转后宽高互换 */ height: 100vw; transform: rotate(90deg); transform-origin: 50% 50%; }这段样式的逻辑是屏幕没转但内容转了。设备竖屏时宽度是100vw高度是100vh旋转 90 度后视觉上的宽变成了原来的高所以容器宽要设成100vh高设成100vw。transform-origin: 50% 50%保证旋转中心在屏幕正中否则容器会跑出可视区。这里有个最容易被忽略的参数transform: rotate(90deg)的旋转方向。不同业务要求的横屏方向不一样——向左转还是向右转直接决定签名区域落在屏幕左侧还是右侧。这套源码默认是rotate(90deg)也就是顺时针旋转适合大多数从左往右书写的场景。如果你的业务需要反方向横屏改成rotate(-90deg)即可注意 canvas 内部坐标会跟着镜像变化后面讲坐标校正时细说。2.2 jSignature 的引入方式与基础初始化拿到源码包后目录结构一般是这样js/jSignature.min.js、js/signature.js业务封装层、css/signature.css外加一个index.html演示页。依赖关系上jSignature 基于 jQuery所以页面里得先引 jQuery 再引 jSignature顺序反了会直接报$.fn.jSignature is not a function。基础的初始化代码在index.html的 script 标签里长这样!-- 注意必须先引 jQuery再引 jSignature.min.js -- script srcjs/jquery.min.js/script script srcjs/jSignature.min.js/script script $(function () { $(#signatureCanvas).jSignature({ width: 600, height: 200, color: #333333, background: #ffffff, lineWidth: 1.5, undo: true }); }); /script参数说明width和height是画布逻辑尺寸不是 CSS 像素尺寸jSignature 内部会在高分屏下做像素密度补偿具体补偿逻辑后面讲踩坑时再说color是笔迹颜色background是签名板背景色这两个可以直接传十六进制字符串lineWidth是笔触宽度默认 1.5 在手机端偏细真机上建议调到 2.5 到 3否则签名笔迹看起来像没墨水的笔写的undo开启后支持撤销上一步笔迹移动端表单场景里这个功能建议开启用户写错了能直接点撤销而不是清空重来。2.3 为什么业务层要自己再包一层封装直接用 jSignature 的 API 在页面上写逻辑短期内能跑但业务一复杂就乱。比如同一个签名板有的场景要同时获取 base64 图片和原始签名数据有的场景要在签名完成后自动压缩图片上传还有的场景要求签名区上方显示“请横屏签名”的提示文案。这些逻辑全部散落在页面里维护成本很高。这套源码在 jSignature 之上封装了一个SignatureBoard对象把常见的操作收敛成几个方法。核心封装逻辑如下function SignatureBoard(selector, options) { this.$el $(selector); this.$el.jSignature($.extend({ width: 600, height: 200, color: #333333, background: #ffffff, lineWidth: 2.5, undo: true }, options || {})); // 清空签名板 this.clear function () { this.$el.jSignature(clear); }; // 获取 base64 图片默认 PNG 格式 this.getBase64 function () { var data this.$el.jSignature(getData, image/png); return data:image/png;base64, data[1]; }; // 获取原始矢量数据可用于回显 this.getRawData function () { return this.$el.jSignature(getData, native); }; // 回显签名传 rawData 数组 this.setRawData function (rawDataArray) { this.$el.jSignature(setData, native, rawDataArray); return this; }; }核心逻辑说明getData(image/png)返回的是数组data[0]是 MIME 类型data[1]才是纯 base64 字符串拼上data:image/png;base64,前缀才能直接给img标签的src用。getData(native)返回的是签名笔迹的矢量坐标数组体积小、可编辑适合存到后端用于签名数据的二次核验。setData(native, rawDataArray)是回显的关键后端把签名数据返回给前端时靠这个方法把笔迹重新画到 canvas 上。3. jSignature 核心 API 实战从签名采集到图片导出3.1 签名数据的三种格式与选型建议jSignature 的getData接口支持多种格式业务里常用的就三种image/png、image/svgxml、native。选哪种取决于你的业务是只要一张图还是需要后续编辑。先看三种格式的实际产出差异。用一个 A4 比例的画布随便签几个字三种格式的数据形态区别明显格式数据形态体积可编辑性适用场景image/pngbase64 字符串中等不可编辑回显、PDF 合成、直接展示image/svgxml矢量路径文本较大可改颜色、笔画打印、高清输出native笔迹坐标点数组最小可重绘、可撤销数据存储、二次核验实际项目中我的选择习惯是数据库里存native数据上传服务器时转成 PNG 图片。理由有两个一是native数据量小签名一笔可能就几百字节而 PNG base64 动辄几万字符存数据库浪费空间二是后端如果想做业务审计比如做人脸比对、签名比对native坐标数据比图片更容易做算法处理。导出 PNG 的关键代码function exportSignatureAsPng(boardInstance) { // 获取 base64 数据jSignature 返回数组第二个元素是纯 base64 var base64Data boardInstance.getBase64(); // 上传时加上业务标识字段 var uploadPayload { signature: base64Data, caseId: $(#caseIdInput).val(), signTime: new Date().getTime() }; // 通过 ajax 发给后端示意代码按实际项目改 URL $.ajax({ url: /api/signature/upload, type: POST, data: JSON.stringify(uploadPayload), contentType: application/json, success: function (resp) { console.log(签名上传成功服务端返回编码, resp.code); }, error: function (err) { console.error(签名上传失败错误对象, err); alert(网络异常签名未能保存请重试。); } }); }参数说明caseIdInput是页面上的业务编号输入框实际项目里可能是一串订单号或合同编号签名必须和业务单关联才有效signTime用时间戳记录签名发生时刻防抵赖场景下这个字段很关键。上传走的contentType是 JSON因为 base64 字符串里可能有、/、这些字符用普通表单提交会被转义容易出问题。3.2 笔迹颜色、背景色与画笔宽度配置jSignature 初始化时的color、background、lineWidth三个参数直接影响最终生成图片的观感和业务合规性。举个例子银行类业务通常要求白底黑字合同签署类可能要求蓝底黑字或者白底蓝字医院知情同意书又要求特定颜色的笔迹。你不可能让业务方等页面出来了再去改代码所以这三个参数应该做成可配置的。源码里的SignatureBoard封装已经考虑了这一点。你可以给构造器传覆盖参数// 白底黑字用于银行开户确认 var bankBoard new SignatureBoard(#bankSignature, { color: #000000, background: #ffffff, lineWidth: 2.5 }); // 浅蓝底深蓝字用于内部审批留痕 var approvalBoard new SignatureBoard(#approvalSignature, { color: #1a3c6e, background: #eef4fb, lineWidth: 2 });背景色和笔迹颜色的对比度不是一个无关紧要的细节。曾有同事直接把默认的白底黑字用在了深色主题的 App 内嵌页里签名弹层背景变成深灰笔迹也是深色用户签名时根本看不清自己写了什么投诉率直线上升。这个问题的根源在于background参数只影响了 jSignature 内部画布的背景而弹层外层容器的 CSS 背景如果是深色的canvas 边缘会露出一圈深色边框视觉上非常突兀。解决方式是把外层容器的背景色也一起配置成和画布一致。lineWidth这个参数需要在真机上反复试。桌面浏览器里 1.5 看起来正常但手机屏幕像素密度高1.5 的笔触在手机上显得特别细尤其是指尖操作屏幕上的落笔点和触摸点天然有偏差笔迹太细的话用户会不自觉地用力按压反而画出歪歪扭扭的线。实测下来 2.5 到 3 是比较舒服的区间既能保证笔迹清晰又不会因为太粗而糊成一团。3.3 清空、撤销与防止误触的设计移动端签名板有三个交互细节直接影响用户是否愿意继续用清空按钮的位置、撤销的步数、以及签名完成后防止误触清空。jSignature 自带clear和undo方法底层是由reset事件和undo事件驱动的。源码封装里的clear()方法直接调用了jSignature(clear)这一步是同步的调用后画布立即清空。这里要注意一个交互问题清空操作是不可逆的如果用户辛辛苦苦签了十几秒误点清空心理打击非常大。常见做法是点击清空后弹一个确认框。代码层面可以这么处理function bindClearButton(board, buttonSelector) { $(buttonSelector).on(click, function () { var r confirm(确认清空当前签名吗此操作不可恢复。); if (r) { board.clear(); // 清空后触发一个自定义事件方便业务方统计 $(document).trigger(signature:cleared); return true; } return false; }); }undo方法属于 jSignature 内部维护的堆栈操作每次执行一次落笔到抬笔的轨迹才记录一步undo操作不是每个像素点都记录。这个设计的好处是内存占用低坏处是如果你在签名过程中间想“只删除最后一笔”没法逐笔细粒度控制。源码里undo: true只是开启了功能真正要触发撤销得调用jSignature(undo)。防止误触还有一层要考虑签名区域的滚动穿透。很多 H5 页面本身是可滚动的用户签名时手指在画布上滑动页面也跟着滚动了笔迹就会断断续续。jSignature 官方没有直接处理滚动穿透源码里在画布外层做了touchmove事件拦截。如果你想自己实现核心思路是$(#signatureCanvas).on(touchmove, function (e) { e.preventDefault(); e.stopPropagation(); });preventDefault()是为了阻止浏览器默认的滚动行为stopPropagation()是为了不让事件冒泡到上层滚动容器。这里有个细微差别只写preventDefault()在部分安卓机型上依然能触发父容器滚动加上stopPropagation()才能彻底切断事件链。这个细节在 iOS 的 WKWebView 上表现一致但安卓 WebView 内核版本差异大必须两层都加。4. 业务集成把签名板嵌进真实表单流程4.1 弹层模式与整页模式的适用场景签名板在 H5 里的承载方式有两种弹层和整页。弹层适合业务流短的场景比如支付确认、风险告知确认用户弹窗签完直接提交整页适合信息填写量大、签名是最后一步的场景比如开户申请表、贷款申请用户从头填到尾最后签名。这套源码默认是整页模式index.html里签名板占据页面主体区域。如果要做成弹层封装里需要额外加一个容器控制层核心逻辑是弹层显示隐藏时初始化或重建签名板。弹层模式的推荐写法function showSignatureModal(callback) { $(#signatureModal).fadeIn(200); // 注意弹层出现时再初始化签名板避免页面加载时 canvas 尺寸为 0 if (!$(#signatureCanvas).hasClass(jSignature-initialized)) { $(#signatureCanvas).jSignature({ width: $(#signatureModal).width() - 40, height: 200, lineWidth: 2.5, undo: true }); $(#signatureCanvas).addClass(jSignature-initialized); } else { // 已初始化过直接清空 $(#signatureCanvas).jSignature(clear); } }这里有一个非常关键的细节弹层刚显示时canvas 的容器宽度是 0。jSignature 在初始化时会读取容器宽度作为画布宽度如果容器还没显示就会渲染成 0 宽度的画布签名区完全看不到。常见做法是弹层fadeIn之后再初始化或者在初始化前手动设置一个固定宽度。源码里没有直接处理这个问题你拿到手做弹层改造时要格外注意。4.2 签名图片的压缩与课后提交移动端网络环境不稳定直接上传一张原始 PNG base64数据量可能在 100KB 到 200KB 之间在弱网环境下上传要好几秒用户体验很差。常见做法是在前端先把图片压一遍再上传。jSignature 官方没有提供压缩接口但getData拿到的 base64 可以直接放到Image对象里再用 canvas 重绘实现压缩function compressSignature(base64Str, maxWidth, quality) { return new Promise(function (resolve, reject) { var img new Image(); img.onload function () { // 按比例缩放 var scale Math.min(maxWidth / img.width, 1); var canvas document.createElement(canvas); canvas.width img.width * scale; canvas.height img.height * scale; var ctx canvas.getContext(2d); ctx.drawImage(img, 0, 0, canvas.width, canvas.height); // quality 范围 0-1建议 0.7 var compressed canvas.toDataURL(image/jpeg, quality); resolve(compressed); }; img.onerror function () { reject(new Error(签名图片解析失败)); }; img.src base64Str; }); }参数说明maxWidth建议设 800签名区域本身就只有 600 像素宽初始化值压到 800 已经够用quality设 0.7 时视觉失真几乎不可感知但体积能缩小一半以上。一个值得注意的细节是toDataURL只支持image/jpeg和image/webp做有损压缩image/png传了quality参数也无效。如果业务要求 PNG 格式就不能用这套压缩逻辑需要另想办法。压缩后的数据再配合第 3.1 节的上传逻辑发送整个签名提交链路就完整了。4.3 后端回显与数据校验的实现签名完成后后端把数据存下来下次打开页面要能看到签名这就是回显。回显有两种数据源图片 base64 和 native 原始数据。图片回显简单一个img标签就完事native 回显需要 jSignature 的setData接口辅助好处是可以再次编辑——比如用户觉得签得不好看可以重新签名覆盖。回显的完整逻辑function loadSignature(board, signatureData) { if (!signatureData) return; // 优先使用 native 数据其次用图片 if (signatureData.nativeData signatureData.nativeData.length 0) { board.setRawData(signatureData.nativeData); } else if (signatureData.imageBase64) { // 图片模式回显直接把 base64 放到画布下方的展示区 $(#signaturePreview).attr(src, signatureData.imageBase64); $(#signaturePreview).show(); } }这里的边界情况如果后端同时返回了 native 数据和图片优先用 native因为setData重绘的笔迹是矢量级的不损失清晰度如果只有图片就没有再编辑的能力。这个取舍要在需求评审阶段和后端对齐否则后端只存了图前端想改就无从下手。还有一层校验逻辑在实践中经常被忽略签名坐标不能为空或空数组。用户手指没有真正落笔就触发保存后端会拿到一个空签名数据这在合同纠纷里是致命的。所以保存前必须检查function isValidSignature(board) { var raw board.getRawData(); // native 数据为空时返回空数组注意是长度为 0 的数组不是 null if (!raw || raw.length 0) { alert(请先完成签名再提交。); return false; } return true; }5. 真机避坑jSignature 签名板常见问题与排查清单5.1 画布模糊设备像素比未正确处理现象真机上签名区域看起来比桌面端模糊笔迹边缘出现锯齿导出图片后放大更明显。原因jSignature 内部创建 canvas 时使用了逻辑尺寸没有乘以window.devicePixelRatio做像素补偿。iPhone 的 DPR 是 3安卓主流机型是 2 到 3逻辑尺寸 600 像素宽的画布物理像素只有 600屏幕上显示时被拉伸自然就糊了。解决初始化后手动扩增 canvas 物理尺寸再用 CSS 缩回逻辑尺寸。示例代码function initHiDPICanvas(canvasId, logicalWidth, logicalHeight) { var canvas document.getElementById(canvasId); var dpr window.devicePixelRatio || 1; // 物理像素尺寸 逻辑尺寸 * DPR canvas.width logicalWidth * dpr; canvas.height logicalHeight * dpr; // CSS 尺寸保持逻辑尺寸 canvas.style.width logicalWidth px; canvas.style.height logicalHeight px; var ctx canvas.getContext(2d); ctx.scale(dpr, dpr); }这个方法只对原生 canvas 生效jSignature 内部封装了自己的画布管理改起来要小心。更稳妥的方式是在初始化 jSignature 之前先判断浏览器环境如果 DPR 大于 1给画布容器加一个transform: scale()的替代方案。实际项目里如果用户只是手机上签个名模糊问题影响不大但如果是平板设备iPad、安卓 Pad屏幕尺寸大模糊感会非常明显必须处理。5.2 签名区域高度为 0画不出来现象页面加载后签名板完全不可见或只显示一条细线点上去没有任何反应。原因jSignature 初始化时容器div的height没有显式设置或者依赖的父容器使用了display: none/visibility: hidden导致初始化阶段读取到的容器宽度和高度都为 0。这个问题常见于弹层模式弹层未显示时初始化签名板jSignature 以 0 高度创建画布。解决初始化前确保容器处于可见状态或者强制给容器设置一个最小高度。代码层面加一层兜底$(#signatureContainer).css({ min-width: 300px, min-height: 150px });这里的核心思路是jSignature 初始化参数里的width和height并不完全等同于容器尺寸它内部会优先读取容器尺寸读不到才用配置项。所以先给容器一个静态高度再初始化就不会踩坑。5.3 安卓 WebView 上笔迹偏移或中断现象同一套代码iOS 上签名正常安卓 WebView 里手指按下后画出的线条偏移 1 到 2 毫米快速滑动时笔迹断断续续。原因安卓 WebView 对 canvas 触摸事件的坐标计算差异。部分机型在 WebView 滚动容器内touch.clientY的值已经包含滚动偏移而 jSignature 内部使用的坐标计算没有正确处理滚动偏移导致笔迹和手指位置不一致。快速滑动断笔则是因为触摸事件采样率不足常见于低端安卓机。解决给签名容器加touch-action: noneCSS 属性禁止浏览器在触摸时执行默认的滚动和缩放逻辑同时在初始化时检查是否有滚动容器嵌套有则给滚动容器绑定scroll事件触发签名板重绘。#signatureCanvas { touch-action: none; -webkit-user-select: none; user-select: none; }touch-action: none能直接杜绝大部分 WebView 的滚动干扰。加了这行之后笔迹偏移问题在绝大多数机型上可以根除。如果加完还有偏移再用开发者工具审查一下页面是否有transform相关的 CSS 动画动画引起的重绘延迟也会导致笔迹偏移。5.4 iOS 上弹层内签名区域显示错位现象iPhone 上打开签名弹层签名区域的上下左右位置不对有时还会露出弹层外的背景内容旋转横屏后位置错得更离谱。原因iOS 上 Safari 和 WKWebView 对position: fixed元素的行为不一致弹层使用了 fixed 定位旋转屏幕时弹层的定位基准发生偏移。此外如果弹层容器内还有 CSS 动画比如fadeIn动画会让弹层在旋转后重新触发定位计算导致错位。解决不用position: fixed改用absolute定位并给弹层外层加一个全屏固定定位的遮罩容器。旋转时触发orientationchange事件重新计算弹层位置。$(window).on(orientationchange, function () { setTimeout(function () { // 等旋转动画结束后重新居中弹层 var modal $(#signatureModal); modal.css({ top: Math.max(0, (window.innerHeight - modal.outerHeight()) / 2) px, left: Math.max(0, (window.innerWidth - modal.outerWidth()) / 2) px }); }, 200); });setTimeout(200)是为了等 iOS 的旋转动画结束立即重算位置会因为高度值还没更新而偏掉。这个 200ms 的经验值在 iOS 上稳定有效安卓 WebView 基本也用不上因为安卓的 fixed 定位表现更接近 Chrome 原生行为。5.5 导出图片后背景色异常现象签名时画布是白色导出 PNG 后背景变成透明放到深色背景页面上看不清签名。原因jSignature 的getData(image/png)导出时不包含背景色信息默认导出透明背景。初始化参数里的background只影响画布显示不影响导出数据。解决导出前先把画布绘制到一张带背景色的离屏 canvas 上再转 base64。function exportWithWhiteBackground(base64Str) { return new Promise(function (resolve) { var img new Image(); img.onload function () { var canvas document.createElement(canvas); canvas.width img.width; canvas.height img.height; var ctx canvas.getContext(2d); // 先铺白底再画签名 ctx.fillStyle #ffffff; ctx.fillRect(0, 0, canvas.width, canvas.height); ctx.drawImage(img, 0, 0); resolve(canvas.toDataURL(image/png)); }; img.src base64Str; }); }这里的逻辑顺序很重要先fillRect再drawImage顺序反了签名会被白色覆盖。这个坑几乎每个接 jSignature 的人都会踩一次很多人第一版上线后运营反馈“签字怎么都变透明了”原因多半在这里。6. 进阶签名板性能优化与数据核验技巧6.1 超大画布下的性能优化策略如果你接入的场景是平板设备画布可能开到 1200 像素宽以上jSignature 的默认渲染性能会明显下降快速签名时出现滞后感。核心原因是笔迹记录的事件点数量大canvas 重绘频次高。一套实测有效的优化思路降低采样率。jSignature 允许你在初始化时监听stroke事件通过记录时间戳控制事件点写入频率var lastWriteTime 0; $(#signatureCanvas).on(stroke, function (e, data) { var now Date.now(); // 30ms 内的重复 stroke 事件直接忽略 if (now - lastWriteTime 30) { return false; } lastWriteTime now; return true; });stroke事件是 jSignature 自定义事件每次笔迹变化都会触发。控制写入频次能减少底层数据量但也会让笔迹失去平滑性。这个优化只建议在真机卡顿明显时开启且采样间隔不要超过 50ms否则签名看起来像折线图。6.2 签名数据的完整性校验方法签名数据的完整性核心是防止“空签名”和“伪造签名”即程序生成的假笔迹。作为前端我们能做的事情有限但有几个技巧值得养成习惯第一签名坐标点的数量检查。正常人签名至少有几个笔段如果native数据里只有一个坐标点极有可能是误触或测试脚本生成的无效签名。第二签名持续时间检查。用户在签名板上从落笔到抬笔的时间通常在 500 毫秒以上低于这个值的基本是意外触碰。前端可以在strokeend事件里记录时间$(#signatureCanvas).on(strokeend, function () { var duration Date.now() - strokeStartTime; if (duration 300) { console.warn(警告当前签名笔画持续时间过短可能为误触或无效签名); } });第三后端校验字段红线签名数据必须和用户 ID、业务单号、时间戳绑定单独存一张图片没有任何防抵赖能力。签名数据表设计时至少要包含这三个字段缺一个出了问题都说不清。6.3 签名板的颜色和尺寸标准化建议最后说一下签名板的标准化。不同业务线的签名板如果各有各的尺寸和颜色用户在同一个 App 里体验不统一合规模块也会很头痛。我的习惯是做一个全局配置对象统一管理var SIGNATURE_CONFIG { // 合同签署场景 contract: { width: 600, height: 200, color: #000000, background: #ffffff, lineWidth: 2.5 }, // 内部审批场景 approval: { width: 500, height: 180, color: #1a3c6e, background: #eef4fb, lineWidth: 2 } }; function getSignatureConfig(scene) { return SIGNATURE_CONFIG[scene] || SIGNATURE_CONFIG.contract; }这样业务方在接入时只需要传场景名不用写一堆魔数。这套源码里的封装只做了基础参数透传实际项目中把配置抽离出来是值得多花十分钟做的重构。从那以后我每次接签名类需求都会强制走一遍这个闭环先确认横屏方向和容器尺寸再在真机上测一遍 DPR 和触摸偏移最后导出图片检查背景色和清晰度。这三个节点任何一个出问题线上就是一次投诉。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/9 18:09:18 · 阅读 1.2k jSignature移动端横屏签名板源码解析与真机避坑指南
简介这套H5横屏签名源码基于jSignature插件实现完整可直接运行面向Web前端开发者与需要快速接入电子签名功能的项目团队重点解决手机横屏状态下手写签名采集、实时回显与图片导出等问题。资源包共69个文件压缩后仅2.98MB主要包括27个js交互脚本、15个css样式文件以及字体、图标、示例页面等配套素材目录结构清晰便于按模块引用或二次开发目前已有1073人学习下载。代码内含jSignature核心插件、jQuery依赖及完整的横屏签名页面运行后可直接在手机上横屏书写并保存为指定格式的签名图片图片格式可自由选择同时附带了相关样式与示例文档方便快速理解调用逻辑。无论是直接部署到业务系统还是参考其横屏布局与签名生成思路进行定制这套资源都能为签名功能开发节省大量从零搭建的时间。1. 移动端签名板选型为什么我最终留下了 jSignature 这套横屏源码H5 页面里做电子签名最容易翻车的不是签名本身而是横屏。很多从业者第一次拿到需求时都很乐观竖屏弹层画个 canvas 不就行了吗真放到手机上一测就露馅——银行开户、保险确认、物业签收这类场景几乎全是横屏表单页面得旋转 90 度canvas 坐标跟着错位手指落笔位置和笔迹偏移能差出半个签名区。这套基于 jSignature 的 H5 签名横屏源码解决的就是这个痛点它把 jSignature 封装进了一个横屏容器里直接运行就能看到签名板旋转、缩放、坐标校正后的真实效果拿到业务里改改接口参数就能用。源码包的完整度对得起“可直接运行”这几个字不依赖特定框架原生 H5 引入 jSignature 库就能跑配了完整的横屏样式和初始化逻辑。适合三类人一是急着交差的业务前端需要一份能跑通的参考实现二是做移动端表单类项目、想了解横屏 canvas 坐标问题怎么处理的开发者三是带外包团队、需要快速验证技术方案的负责人。下面从横屏方案、初始化配置、业务功能封装到真实设备避坑一条线拆完。2. 横屏签名板先解决画布旋转再谈笔迹采集2.1 竖屏转横屏的两种实现路径对比H5 里做横屏主流做法无非两种CSS transform 旋转整个页面或者依赖原生 API 强制横屏。先说结论这套源码选的是前者因为后者的兼容性坑太多——安卓碎片化严重微信内置浏览器对强制横屏的 API 支持不统一iOS 上 Safari 对旋转 API 的响应时好时坏线上环境出了问题你连复现都得看用户手机型号脸色。CSS transform 方案的思路是把整个应用容器旋转 90 度再用视口宽高换算补偿旋转后的布局尺寸。核心就三行样式.app-canvas-wrapper { position: fixed; top: 0; left: 0; width: 100vh; /* 旋转后宽高互换 */ height: 100vw; transform: rotate(90deg); transform-origin: 50% 50%; }这段样式的逻辑是屏幕没转但内容转了。设备竖屏时宽度是100vw高度是100vh旋转 90 度后视觉上的宽变成了原来的高所以容器宽要设成100vh高设成100vw。transform-origin: 50% 50%保证旋转中心在屏幕正中否则容器会跑出可视区。这里有个最容易被忽略的参数transform: rotate(90deg)的旋转方向。不同业务要求的横屏方向不一样——向左转还是向右转直接决定签名区域落在屏幕左侧还是右侧。这套源码默认是rotate(90deg)也就是顺时针旋转适合大多数从左往右书写的场景。如果你的业务需要反方向横屏改成rotate(-90deg)即可注意 canvas 内部坐标会跟着镜像变化后面讲坐标校正时细说。2.2 jSignature 的引入方式与基础初始化拿到源码包后目录结构一般是这样js/jSignature.min.js、js/signature.js业务封装层、css/signature.css外加一个index.html演示页。依赖关系上jSignature 基于 jQuery所以页面里得先引 jQuery 再引 jSignature顺序反了会直接报$.fn.jSignature is not a function。基础的初始化代码在index.html的 script 标签里长这样!-- 注意必须先引 jQuery再引 jSignature.min.js -- script srcjs/jquery.min.js/script script srcjs/jSignature.min.js/script script $(function () { $(#signatureCanvas).jSignature({ width: 600, height: 200, color: #333333, background: #ffffff, lineWidth: 1.5, undo: true }); }); /script参数说明width和height是画布逻辑尺寸不是 CSS 像素尺寸jSignature 内部会在高分屏下做像素密度补偿具体补偿逻辑后面讲踩坑时再说color是笔迹颜色background是签名板背景色这两个可以直接传十六进制字符串lineWidth是笔触宽度默认 1.5 在手机端偏细真机上建议调到 2.5 到 3否则签名笔迹看起来像没墨水的笔写的undo开启后支持撤销上一步笔迹移动端表单场景里这个功能建议开启用户写错了能直接点撤销而不是清空重来。2.3 为什么业务层要自己再包一层封装直接用 jSignature 的 API 在页面上写逻辑短期内能跑但业务一复杂就乱。比如同一个签名板有的场景要同时获取 base64 图片和原始签名数据有的场景要在签名完成后自动压缩图片上传还有的场景要求签名区上方显示“请横屏签名”的提示文案。这些逻辑全部散落在页面里维护成本很高。这套源码在 jSignature 之上封装了一个SignatureBoard对象把常见的操作收敛成几个方法。核心封装逻辑如下function SignatureBoard(selector, options) { this.$el $(selector); this.$el.jSignature($.extend({ width: 600, height: 200, color: #333333, background: #ffffff, lineWidth: 2.5, undo: true }, options || {})); // 清空签名板 this.clear function () { this.$el.jSignature(clear); }; // 获取 base64 图片默认 PNG 格式 this.getBase64 function () { var data this.$el.jSignature(getData, image/png); return data:image/png;base64, data[1]; }; // 获取原始矢量数据可用于回显 this.getRawData function () { return this.$el.jSignature(getData, native); }; // 回显签名传 rawData 数组 this.setRawData function (rawDataArray) { this.$el.jSignature(setData, native, rawDataArray); return this; }; }核心逻辑说明getData(image/png)返回的是数组data[0]是 MIME 类型data[1]才是纯 base64 字符串拼上data:image/png;base64,前缀才能直接给img标签的src用。getData(native)返回的是签名笔迹的矢量坐标数组体积小、可编辑适合存到后端用于签名数据的二次核验。setData(native, rawDataArray)是回显的关键后端把签名数据返回给前端时靠这个方法把笔迹重新画到 canvas 上。3. jSignature 核心 API 实战从签名采集到图片导出3.1 签名数据的三种格式与选型建议jSignature 的getData接口支持多种格式业务里常用的就三种image/png、image/svgxml、native。选哪种取决于你的业务是只要一张图还是需要后续编辑。先看三种格式的实际产出差异。用一个 A4 比例的画布随便签几个字三种格式的数据形态区别明显格式数据形态体积可编辑性适用场景image/pngbase64 字符串中等不可编辑回显、PDF 合成、直接展示image/svgxml矢量路径文本较大可改颜色、笔画打印、高清输出native笔迹坐标点数组最小可重绘、可撤销数据存储、二次核验实际项目中我的选择习惯是数据库里存native数据上传服务器时转成 PNG 图片。理由有两个一是native数据量小签名一笔可能就几百字节而 PNG base64 动辄几万字符存数据库浪费空间二是后端如果想做业务审计比如做人脸比对、签名比对native坐标数据比图片更容易做算法处理。导出 PNG 的关键代码function exportSignatureAsPng(boardInstance) { // 获取 base64 数据jSignature 返回数组第二个元素是纯 base64 var base64Data boardInstance.getBase64(); // 上传时加上业务标识字段 var uploadPayload { signature: base64Data, caseId: $(#caseIdInput).val(), signTime: new Date().getTime() }; // 通过 ajax 发给后端示意代码按实际项目改 URL $.ajax({ url: /api/signature/upload, type: POST, data: JSON.stringify(uploadPayload), contentType: application/json, success: function (resp) { console.log(签名上传成功服务端返回编码, resp.code); }, error: function (err) { console.error(签名上传失败错误对象, err); alert(网络异常签名未能保存请重试。); } }); }参数说明caseIdInput是页面上的业务编号输入框实际项目里可能是一串订单号或合同编号签名必须和业务单关联才有效signTime用时间戳记录签名发生时刻防抵赖场景下这个字段很关键。上传走的contentType是 JSON因为 base64 字符串里可能有、/、这些字符用普通表单提交会被转义容易出问题。3.2 笔迹颜色、背景色与画笔宽度配置jSignature 初始化时的color、background、lineWidth三个参数直接影响最终生成图片的观感和业务合规性。举个例子银行类业务通常要求白底黑字合同签署类可能要求蓝底黑字或者白底蓝字医院知情同意书又要求特定颜色的笔迹。你不可能让业务方等页面出来了再去改代码所以这三个参数应该做成可配置的。源码里的SignatureBoard封装已经考虑了这一点。你可以给构造器传覆盖参数// 白底黑字用于银行开户确认 var bankBoard new SignatureBoard(#bankSignature, { color: #000000, background: #ffffff, lineWidth: 2.5 }); // 浅蓝底深蓝字用于内部审批留痕 var approvalBoard new SignatureBoard(#approvalSignature, { color: #1a3c6e, background: #eef4fb, lineWidth: 2 });背景色和笔迹颜色的对比度不是一个无关紧要的细节。曾有同事直接把默认的白底黑字用在了深色主题的 App 内嵌页里签名弹层背景变成深灰笔迹也是深色用户签名时根本看不清自己写了什么投诉率直线上升。这个问题的根源在于background参数只影响了 jSignature 内部画布的背景而弹层外层容器的 CSS 背景如果是深色的canvas 边缘会露出一圈深色边框视觉上非常突兀。解决方式是把外层容器的背景色也一起配置成和画布一致。lineWidth这个参数需要在真机上反复试。桌面浏览器里 1.5 看起来正常但手机屏幕像素密度高1.5 的笔触在手机上显得特别细尤其是指尖操作屏幕上的落笔点和触摸点天然有偏差笔迹太细的话用户会不自觉地用力按压反而画出歪歪扭扭的线。实测下来 2.5 到 3 是比较舒服的区间既能保证笔迹清晰又不会因为太粗而糊成一团。3.3 清空、撤销与防止误触的设计移动端签名板有三个交互细节直接影响用户是否愿意继续用清空按钮的位置、撤销的步数、以及签名完成后防止误触清空。jSignature 自带clear和undo方法底层是由reset事件和undo事件驱动的。源码封装里的clear()方法直接调用了jSignature(clear)这一步是同步的调用后画布立即清空。这里要注意一个交互问题清空操作是不可逆的如果用户辛辛苦苦签了十几秒误点清空心理打击非常大。常见做法是点击清空后弹一个确认框。代码层面可以这么处理function bindClearButton(board, buttonSelector) { $(buttonSelector).on(click, function () { var r confirm(确认清空当前签名吗此操作不可恢复。); if (r) { board.clear(); // 清空后触发一个自定义事件方便业务方统计 $(document).trigger(signature:cleared); return true; } return false; }); }undo方法属于 jSignature 内部维护的堆栈操作每次执行一次落笔到抬笔的轨迹才记录一步undo操作不是每个像素点都记录。这个设计的好处是内存占用低坏处是如果你在签名过程中间想“只删除最后一笔”没法逐笔细粒度控制。源码里undo: true只是开启了功能真正要触发撤销得调用jSignature(undo)。防止误触还有一层要考虑签名区域的滚动穿透。很多 H5 页面本身是可滚动的用户签名时手指在画布上滑动页面也跟着滚动了笔迹就会断断续续。jSignature 官方没有直接处理滚动穿透源码里在画布外层做了touchmove事件拦截。如果你想自己实现核心思路是$(#signatureCanvas).on(touchmove, function (e) { e.preventDefault(); e.stopPropagation(); });preventDefault()是为了阻止浏览器默认的滚动行为stopPropagation()是为了不让事件冒泡到上层滚动容器。这里有个细微差别只写preventDefault()在部分安卓机型上依然能触发父容器滚动加上stopPropagation()才能彻底切断事件链。这个细节在 iOS 的 WKWebView 上表现一致但安卓 WebView 内核版本差异大必须两层都加。4. 业务集成把签名板嵌进真实表单流程4.1 弹层模式与整页模式的适用场景签名板在 H5 里的承载方式有两种弹层和整页。弹层适合业务流短的场景比如支付确认、风险告知确认用户弹窗签完直接提交整页适合信息填写量大、签名是最后一步的场景比如开户申请表、贷款申请用户从头填到尾最后签名。这套源码默认是整页模式index.html里签名板占据页面主体区域。如果要做成弹层封装里需要额外加一个容器控制层核心逻辑是弹层显示隐藏时初始化或重建签名板。弹层模式的推荐写法function showSignatureModal(callback) { $(#signatureModal).fadeIn(200); // 注意弹层出现时再初始化签名板避免页面加载时 canvas 尺寸为 0 if (!$(#signatureCanvas).hasClass(jSignature-initialized)) { $(#signatureCanvas).jSignature({ width: $(#signatureModal).width() - 40, height: 200, lineWidth: 2.5, undo: true }); $(#signatureCanvas).addClass(jSignature-initialized); } else { // 已初始化过直接清空 $(#signatureCanvas).jSignature(clear); } }这里有一个非常关键的细节弹层刚显示时canvas 的容器宽度是 0。jSignature 在初始化时会读取容器宽度作为画布宽度如果容器还没显示就会渲染成 0 宽度的画布签名区完全看不到。常见做法是弹层fadeIn之后再初始化或者在初始化前手动设置一个固定宽度。源码里没有直接处理这个问题你拿到手做弹层改造时要格外注意。4.2 签名图片的压缩与课后提交移动端网络环境不稳定直接上传一张原始 PNG base64数据量可能在 100KB 到 200KB 之间在弱网环境下上传要好几秒用户体验很差。常见做法是在前端先把图片压一遍再上传。jSignature 官方没有提供压缩接口但getData拿到的 base64 可以直接放到Image对象里再用 canvas 重绘实现压缩function compressSignature(base64Str, maxWidth, quality) { return new Promise(function (resolve, reject) { var img new Image(); img.onload function () { // 按比例缩放 var scale Math.min(maxWidth / img.width, 1); var canvas document.createElement(canvas); canvas.width img.width * scale; canvas.height img.height * scale; var ctx canvas.getContext(2d); ctx.drawImage(img, 0, 0, canvas.width, canvas.height); // quality 范围 0-1建议 0.7 var compressed canvas.toDataURL(image/jpeg, quality); resolve(compressed); }; img.onerror function () { reject(new Error(签名图片解析失败)); }; img.src base64Str; }); }参数说明maxWidth建议设 800签名区域本身就只有 600 像素宽初始化值压到 800 已经够用quality设 0.7 时视觉失真几乎不可感知但体积能缩小一半以上。一个值得注意的细节是toDataURL只支持image/jpeg和image/webp做有损压缩image/png传了quality参数也无效。如果业务要求 PNG 格式就不能用这套压缩逻辑需要另想办法。压缩后的数据再配合第 3.1 节的上传逻辑发送整个签名提交链路就完整了。4.3 后端回显与数据校验的实现签名完成后后端把数据存下来下次打开页面要能看到签名这就是回显。回显有两种数据源图片 base64 和 native 原始数据。图片回显简单一个img标签就完事native 回显需要 jSignature 的setData接口辅助好处是可以再次编辑——比如用户觉得签得不好看可以重新签名覆盖。回显的完整逻辑function loadSignature(board, signatureData) { if (!signatureData) return; // 优先使用 native 数据其次用图片 if (signatureData.nativeData signatureData.nativeData.length 0) { board.setRawData(signatureData.nativeData); } else if (signatureData.imageBase64) { // 图片模式回显直接把 base64 放到画布下方的展示区 $(#signaturePreview).attr(src, signatureData.imageBase64); $(#signaturePreview).show(); } }这里的边界情况如果后端同时返回了 native 数据和图片优先用 native因为setData重绘的笔迹是矢量级的不损失清晰度如果只有图片就没有再编辑的能力。这个取舍要在需求评审阶段和后端对齐否则后端只存了图前端想改就无从下手。还有一层校验逻辑在实践中经常被忽略签名坐标不能为空或空数组。用户手指没有真正落笔就触发保存后端会拿到一个空签名数据这在合同纠纷里是致命的。所以保存前必须检查function isValidSignature(board) { var raw board.getRawData(); // native 数据为空时返回空数组注意是长度为 0 的数组不是 null if (!raw || raw.length 0) { alert(请先完成签名再提交。); return false; } return true; }5. 真机避坑jSignature 签名板常见问题与排查清单5.1 画布模糊设备像素比未正确处理现象真机上签名区域看起来比桌面端模糊笔迹边缘出现锯齿导出图片后放大更明显。原因jSignature 内部创建 canvas 时使用了逻辑尺寸没有乘以window.devicePixelRatio做像素补偿。iPhone 的 DPR 是 3安卓主流机型是 2 到 3逻辑尺寸 600 像素宽的画布物理像素只有 600屏幕上显示时被拉伸自然就糊了。解决初始化后手动扩增 canvas 物理尺寸再用 CSS 缩回逻辑尺寸。示例代码function initHiDPICanvas(canvasId, logicalWidth, logicalHeight) { var canvas document.getElementById(canvasId); var dpr window.devicePixelRatio || 1; // 物理像素尺寸 逻辑尺寸 * DPR canvas.width logicalWidth * dpr; canvas.height logicalHeight * dpr; // CSS 尺寸保持逻辑尺寸 canvas.style.width logicalWidth px; canvas.style.height logicalHeight px; var ctx canvas.getContext(2d); ctx.scale(dpr, dpr); }这个方法只对原生 canvas 生效jSignature 内部封装了自己的画布管理改起来要小心。更稳妥的方式是在初始化 jSignature 之前先判断浏览器环境如果 DPR 大于 1给画布容器加一个transform: scale()的替代方案。实际项目里如果用户只是手机上签个名模糊问题影响不大但如果是平板设备iPad、安卓 Pad屏幕尺寸大模糊感会非常明显必须处理。5.2 签名区域高度为 0画不出来现象页面加载后签名板完全不可见或只显示一条细线点上去没有任何反应。原因jSignature 初始化时容器div的height没有显式设置或者依赖的父容器使用了display: none/visibility: hidden导致初始化阶段读取到的容器宽度和高度都为 0。这个问题常见于弹层模式弹层未显示时初始化签名板jSignature 以 0 高度创建画布。解决初始化前确保容器处于可见状态或者强制给容器设置一个最小高度。代码层面加一层兜底$(#signatureContainer).css({ min-width: 300px, min-height: 150px });这里的核心思路是jSignature 初始化参数里的width和height并不完全等同于容器尺寸它内部会优先读取容器尺寸读不到才用配置项。所以先给容器一个静态高度再初始化就不会踩坑。5.3 安卓 WebView 上笔迹偏移或中断现象同一套代码iOS 上签名正常安卓 WebView 里手指按下后画出的线条偏移 1 到 2 毫米快速滑动时笔迹断断续续。原因安卓 WebView 对 canvas 触摸事件的坐标计算差异。部分机型在 WebView 滚动容器内touch.clientY的值已经包含滚动偏移而 jSignature 内部使用的坐标计算没有正确处理滚动偏移导致笔迹和手指位置不一致。快速滑动断笔则是因为触摸事件采样率不足常见于低端安卓机。解决给签名容器加touch-action: noneCSS 属性禁止浏览器在触摸时执行默认的滚动和缩放逻辑同时在初始化时检查是否有滚动容器嵌套有则给滚动容器绑定scroll事件触发签名板重绘。#signatureCanvas { touch-action: none; -webkit-user-select: none; user-select: none; }touch-action: none能直接杜绝大部分 WebView 的滚动干扰。加了这行之后笔迹偏移问题在绝大多数机型上可以根除。如果加完还有偏移再用开发者工具审查一下页面是否有transform相关的 CSS 动画动画引起的重绘延迟也会导致笔迹偏移。5.4 iOS 上弹层内签名区域显示错位现象iPhone 上打开签名弹层签名区域的上下左右位置不对有时还会露出弹层外的背景内容旋转横屏后位置错得更离谱。原因iOS 上 Safari 和 WKWebView 对position: fixed元素的行为不一致弹层使用了 fixed 定位旋转屏幕时弹层的定位基准发生偏移。此外如果弹层容器内还有 CSS 动画比如fadeIn动画会让弹层在旋转后重新触发定位计算导致错位。解决不用position: fixed改用absolute定位并给弹层外层加一个全屏固定定位的遮罩容器。旋转时触发orientationchange事件重新计算弹层位置。$(window).on(orientationchange, function () { setTimeout(function () { // 等旋转动画结束后重新居中弹层 var modal $(#signatureModal); modal.css({ top: Math.max(0, (window.innerHeight - modal.outerHeight()) / 2) px, left: Math.max(0, (window.innerWidth - modal.outerWidth()) / 2) px }); }, 200); });setTimeout(200)是为了等 iOS 的旋转动画结束立即重算位置会因为高度值还没更新而偏掉。这个 200ms 的经验值在 iOS 上稳定有效安卓 WebView 基本也用不上因为安卓的 fixed 定位表现更接近 Chrome 原生行为。5.5 导出图片后背景色异常现象签名时画布是白色导出 PNG 后背景变成透明放到深色背景页面上看不清签名。原因jSignature 的getData(image/png)导出时不包含背景色信息默认导出透明背景。初始化参数里的background只影响画布显示不影响导出数据。解决导出前先把画布绘制到一张带背景色的离屏 canvas 上再转 base64。function exportWithWhiteBackground(base64Str) { return new Promise(function (resolve) { var img new Image(); img.onload function () { var canvas document.createElement(canvas); canvas.width img.width; canvas.height img.height; var ctx canvas.getContext(2d); // 先铺白底再画签名 ctx.fillStyle #ffffff; ctx.fillRect(0, 0, canvas.width, canvas.height); ctx.drawImage(img, 0, 0); resolve(canvas.toDataURL(image/png)); }; img.src base64Str; }); }这里的逻辑顺序很重要先fillRect再drawImage顺序反了签名会被白色覆盖。这个坑几乎每个接 jSignature 的人都会踩一次很多人第一版上线后运营反馈“签字怎么都变透明了”原因多半在这里。6. 进阶签名板性能优化与数据核验技巧6.1 超大画布下的性能优化策略如果你接入的场景是平板设备画布可能开到 1200 像素宽以上jSignature 的默认渲染性能会明显下降快速签名时出现滞后感。核心原因是笔迹记录的事件点数量大canvas 重绘频次高。一套实测有效的优化思路降低采样率。jSignature 允许你在初始化时监听stroke事件通过记录时间戳控制事件点写入频率var lastWriteTime 0; $(#signatureCanvas).on(stroke, function (e, data) { var now Date.now(); // 30ms 内的重复 stroke 事件直接忽略 if (now - lastWriteTime 30) { return false; } lastWriteTime now; return true; });stroke事件是 jSignature 自定义事件每次笔迹变化都会触发。控制写入频次能减少底层数据量但也会让笔迹失去平滑性。这个优化只建议在真机卡顿明显时开启且采样间隔不要超过 50ms否则签名看起来像折线图。6.2 签名数据的完整性校验方法签名数据的完整性核心是防止“空签名”和“伪造签名”即程序生成的假笔迹。作为前端我们能做的事情有限但有几个技巧值得养成习惯第一签名坐标点的数量检查。正常人签名至少有几个笔段如果native数据里只有一个坐标点极有可能是误触或测试脚本生成的无效签名。第二签名持续时间检查。用户在签名板上从落笔到抬笔的时间通常在 500 毫秒以上低于这个值的基本是意外触碰。前端可以在strokeend事件里记录时间$(#signatureCanvas).on(strokeend, function () { var duration Date.now() - strokeStartTime; if (duration 300) { console.warn(警告当前签名笔画持续时间过短可能为误触或无效签名); } });第三后端校验字段红线签名数据必须和用户 ID、业务单号、时间戳绑定单独存一张图片没有任何防抵赖能力。签名数据表设计时至少要包含这三个字段缺一个出了问题都说不清。6.3 签名板的颜色和尺寸标准化建议最后说一下签名板的标准化。不同业务线的签名板如果各有各的尺寸和颜色用户在同一个 App 里体验不统一合规模块也会很头痛。我的习惯是做一个全局配置对象统一管理var SIGNATURE_CONFIG { // 合同签署场景 contract: { width: 600, height: 200, color: #000000, background: #ffffff, lineWidth: 2.5 }, // 内部审批场景 approval: { width: 500, height: 180, color: #1a3c6e, background: #eef4fb, lineWidth: 2 } }; function getSignatureConfig(scene) { return SIGNATURE_CONFIG[scene] || SIGNATURE_CONFIG.contract; }这样业务方在接入时只需要传场景名不用写一堆魔数。这套源码里的封装只做了基础参数透传实际项目中把配置抽离出来是值得多花十分钟做的重构。从那以后我每次接签名类需求都会强制走一遍这个闭环先确认横屏方向和容器尺寸再在真机上测一遍 DPR 和触摸偏移最后导出图片检查背景色和清晰度。这三个节点任何一个出问题线上就是一次投诉。希望帮到你。本文还有配套的精品资源点击获取