简介面向手机端T恤在线定制场景这套基于HTML5 Canvas的DIY设计系统源码适合前端开发者、交互设计师及电商平台从业者学习参考。压缩包大小14.19MB内部主要包含入口HTML页面、图片素材、JavaScript交互脚本、字体库及CSS样式表对应模板展示、元素拖拽、文字叠加等核心功能模块。已有796人学习下载。系统已搭建好基础框架但文字尚未完全写入画布开发者可借此深入理解绘图、事件绑定与设计保存流程也可继续完善文字图形合成、扩展字体库或引入现代化框架优化交互。整体上这份源码兼顾技术实践与产品思维可用于课程设计、毕业设计或商业定制项目开发起点同时为理解移动端DIY工具的前后端协作提供完整参考对希望掌握Canvas绘图与移动端交互设计的开发者是难得的实战素材。1. T恤DIY定制系统在解决什么问题从设计画布到印刷文件的一站式链路一个用户在前端拖了张图、打了行字3分钟生成一件“设计稿”这看着是电商标配功能但真正上线后最先翻车的往往不是下单支付而是画布导出的图要么模糊、要么偏色、要么字体乱码印到实物上跟屏幕上完全是两件衣服。T恤DIY定制系统解决的核心问题是把“在线设计交互”和“可印刷文件”这条链路打通前端负责让用户改到满意后端负责把设计数据可靠地存下来、生成预览、算价、下单最后交给印刷环节。这套方案适合两类人一类是准备上线定制商城、想快速有可跑Demo的运营或技术负责人另一类是正在自研类似功能、想知道设计器模块怎么拆、怎么跟订单系统对接的开发者。下面我按从部署到二次开发的顺序把系统里真正影响成败的参数和坑讲清楚。2. 先把系统跑起来从解压zip包到页面出图的部署路径2.1 典型工程结构与运行环境确认拿到zip包解压后常见的前后端分离结构是这样后端是一个Java Spring Boot应用负责商品、订单、支付回调、文件存储前端是一个Vue项目包含商城页和设计画布页另外带一个初始化SQL脚本里面是商品表、订单表和设计图层表。我一般在动手前先确认三件事JDK版本、Node版本、MySQL版本。版本不对后面编译报错会浪费大量时间。运行环境确认表组件版本要求说明JDK1.8及以上过低版本无法运行Spring Boot 2.xMySQL5.7及以上设计图层JSON字段需要utf8mb4支持Node.js14及以上前端画布依赖新版浏览器特性Maven3.6及以上后端依赖打包这套组合的好处是画布相关的内存开销都在前端浏览器里后端只做数据存取和文件转发单机部署就能支撑中小型定制业务。如果后续要做集群只需要把上传目录挪到OSS并把会话改成Redis这是后话一开始不用过度设计。2.2 数据库初始化design_layer表是命根子SQL脚本导入后要重点确认四张核心表product、product_sku、orders、design_layer。很多部署翻车都是因为只导了部分表或者漏了design_layer表。这张表存的是用户画布上每个图层的JSON快照没有它用户刷新页面就看不到历史设计下单后的设计稿也无法回溯。所以导入后第一步是查表清单。mysql -uroot -p tshirt_db design.sql mysql -uroot -p -e show tables from tshirt_db;第一行命令把初始化脚本导入数据库第二行列出所有表确认design_layer存在。如果发现表缺失不要手动建回去重新执行完整脚本更稳妥因为表之间有关联。注意导入时数据库字符集要指定utf8mb4否则表情符号和生僻字会变成问号。2.3 后端启动上传目录和静态映射必须对齐启动后端前打开application.yml里面有三个配置决定后面会不会出问题文件上传目录、图片URL映射前缀、数据库连接串。上传目录必须和静态资源映射对齐否则文件传上去了前端的img标签加载不出图。这里给一份常用的配置片段。spring: servlet: multipart: max-file-size: 10MB max-request-size: 10MB web: resources: static-locations: file:${upload.dir} upload: dir: /data/tshirt/upload参数说明max-file-size限制单张图片大小10MB对高清素材够用static-locations把本地目录暴露成静态资源这样上传的图片能通过URL直接访问。upload.dir建议放在应用外部不要放jar包同目录否则每次发版都要拷数据。后面前端生成的设计图也会存到这个目录再按订单号归档。2.4 前端启动开发态代理和Nginx反代前端工程的package.json里scripts一般有dev和build。开发态跑dev时Vite或Webpack会监听5173或8080端口但接口请求必须转发到后端。常见做法是在vite.config.js里配proxy把/api开头的请求转给后端端口。如果直接打包部署dist目录扔给Nginx也要在nginx.conf里做一层反向代理。npm install npm run devnpm install装依赖时如果网络不稳定会出现装一半失败的灵异现象我的习惯是装完立刻跑npm run build做一次冒烟验证能出dist就说明依赖没问题。生产部署时把dist放到Nginx的html目录再在配置里加一条location /api的反向代理。这一步漏了前端页面能打开但登录接口永远404很多人花一下午排查其实就是代理没配。3. 设计画布的核心图层模型、图片上传与文字编辑3.1 画布最小数据结构整个设计就是一个JSON数组T恤设计器的本质是图层编辑器。用户往画布上每拖一张图、每打一行字都是在新增一个图层。图层数据一定要序列化成JSON保存这是后续重新编辑、重新导出高清图的前提。最小图层结构是类型、位置、缩放、旋转、内容。文字层和图片层的字段略有差异。{ id: layer_001, type: text, left: 120, top: 80, scaleX: 1.0, scaleY: 1.0, angle: 0, content: KEEP IT REAL, fontFamily: MyFont-Bold, fontSize: 42, fill: #ffffff }参数说明left和top是图层左上角在画布上的像素坐标scaleX和scaleY是缩放比例不直接改宽度高度避免文字缩放后字体被拉伸变形angle是旋转角度用于做斜排效果content在文字层存字符串在图片层存图片URL。这套JSON就是整个设计稿的“后悔药”用户下单后想改文案只要改这一个字段重新导出就行不用重新做图。3.2 图片上传先压缩再进画布别把原图塞进去很多人在这一步踩坑用户上传一张手机拍的5MB照片直接画进canvas导出时浏览器内存直接爆掉。我一般上传后先在客户端做一次压缩把超过2000像素的图片等比缩到2000以内然后才放进画布。这样既保证屏幕显示清晰又不会让浏览器内存飙升。function compressImage(file, maxSize 2000, quality 0.85) { return new Promise((resolve) { const reader new FileReader(); reader.onload (e) { const img new Image(); img.onload () { const scale Math.min(1, maxSize / Math.max(img.width, img.height)); const canvas document.createElement(canvas); canvas.width Math.round(img.width * scale); canvas.height Math.round(img.height * scale); const ctx canvas.getContext(2d); ctx.drawImage(img, 0, 0, canvas.width, canvas.height); resolve(canvas.toDataURL(image/jpeg, quality)); }; img.src e.target.result; }; reader.readAsDataURL(file); }); }逻辑说明FileReader把文件读成base64Image对象加载后计算缩放比例drawImage绘制到临时画布最后转成JPEG格式的dataURL。参数说明maxSize取2000是兼顾清晰度和内存的折中值quality取0.85是肉眼基本无损的压缩点低于0.7会出现可见色块。压缩后的base64字符串可以直接存进图层的content字段也可以上传到服务器换成URL再存前者实现简单后者减少数据库体积生产环境建议后者。3.3 文字编辑字体加载是乱码问题的根源画布上的文字要跟用户选的字型一致必须在浏览器里先加载好字体文件。很多人直接设置canvas的font属性为“微软雅黑”或“Arial”这没问题但一旦用户选的是网上下载的装饰字体canvas会fallback到默认字体预览和导出效果完全不一样。正确做法是用FontFace API主动加载等字体就绪后再渲染。async function loadFont(fontName, fontUrl) { const font new FontFace(fontName, url(${fontUrl})); await font.load(); document.fonts.add(font); await document.fonts.load(16px ${fontName}); }逻辑说明第一步通过FontFace构建字体对象第二步load()拉取字体文件第三步把字体注册到document.fonts第四步触发一次实际的文字渲染让字体缓存生效。之后canvas里设置fontFamily时才能匹配上。注意字体文件必须支持跨域访问如果前端站点和字体文件不在同一个域名服务器要返回Access-Control-Allow-Origin头否则FontFace加载会被浏览器拦截。另外字体版权要注意商用字体需要授权建议内置开源或已购买商用授权的字体用户上传的字体文件由用户自己负责版权。3.4 导出设计稿300DPI的像素数到底怎么算这是整个系统里最容易被忽略的一环。屏幕上的画布分辨率一般是150像素左右看着很清楚但印刷需要300DPI。一件T恤的常用印花区域是10英寸乘12英寸按300DPI换算像素就是3000乘3600。如果直接把屏幕画布导出印出来全是锯齿。function exportPrintImage(designJson, dpi 300) { const printWidthInch 10; const printHeightInch 12; const canvas document.createElement(canvas); canvas.width Math.round(printWidthInch * dpi); canvas.height Math.round(printHeightInch * dpi); const ctx canvas.getContext(2d); // 按设计稿JSON逐层绘制绘制前先放大scale ctx.scale(2, 2); drawLayers(ctx, designJson.layers); canvas.toBlob((blob) { // 上传blob到后端 }, image/png); }参数说明dpi取300是印刷行业通用标准印小图案可以降到200但不要低于150printWidthInch和printHeightInch是实际印花尺寸需要跟T恤模板的印刷区域对应。关键点是导出的画布尺寸按实际英寸乘dpi计算而不是屏幕像素。绘制时把图层的left、top、fontSize都按比例放大这样导出图就是印刷级清晰度。屏幕上的画布预览可以用低分辨率导出时用高分辨率两个canvas互不影响。4. 从设计稿到订单计价、预览图和支付回调的闭环4.1 价格规则基础价加面积加件数折扣定制T恤的价格不是一口价常见计价公式是基础T恤价格 印花面积档位价 件数折扣。基础价由款式和尺码决定放在product_sku表里印花面积分两档小于A4一个价大于A4加价。这个规则要落进数据库方便运营调整。CREATE TABLE product_sku ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL, style VARCHAR(32) NOT NULL, size VARCHAR(8) NOT NULL, base_price DECIMAL(10,2) NOT NULL, print_area_code VARCHAR(16) NOT NULL ); CREATE TABLE print_area_price ( area_code VARCHAR(16) PRIMARY KEY, area_name VARCHAR(64) NOT NULL, max_width_cm INT NOT NULL, max_height_cm INT NOT NULL, extra_price DECIMAL(10,2) NOT NULL );说明里面有两个关键点print_area_code关联到具体的印花区域比如前胸、后背、袖子不同区域的尺寸上限和加价不一样折扣逻辑不要在SQL里算用代码算因为要叠加用户等级和促销活动。我之前见过有人把折扣写进存储过程结果每次调价都要改函数维护成本很高。4.2 预览图SVG蒙版还是多角度贴图设计器旁边要有一个“效果预览”让用户看到设计图穿在T恤上的样子。两种常见做法SVG蒙版和预渲染多角度贴图。SVG蒙版是把T恤照片的印花区域做成路径设计图作为填充图案优点是加载快、可交互多角度贴图是后端用图像处理预渲染正反面效果图优点是真实感强缺点是每改一次设计都要重新生成。方案优点缺点SVG蒙版实时响应、文件小光照纹理失真多角度贴图真实感强、细节丰富渲染慢、需要队列我的经验是前端做SVG蒙版用于实时预览下单后后端生成一张高清多角度图用于详情页两者各有分工。实时预览响应要快用户拖动图层时蒙版跟着变详情页图片要稳定生成一次存下来就行。不用让一个方案扛两种需求。4.3 订单表设计设计稿快照必须存JSON不要只存图片订单表除了常规的收货信息和支付状态必须有一个字段存设计稿JSON。这个设计稿JSON就是当时画布上所有图层的完整快照。为什么不能只存导出的PNG因为用户可能在下单后发现文字有错别字没有JSON就得重新拼一版图有了JSON直接改content字段重新导出即可。CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, design_snapshot TEXT NOT NULL, preview_image_url VARCHAR(255) NOT NULL, sku_json VARCHAR(512) NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP );参数说明design_snapshot用TEXT类型存JSON字符串不要用VARCHAR因为多个图层的JSON很容易超过255字符preview_image_url存的是下单时生成的预览图用于用户订单列表展示sku_json存款式、尺码、颜色等下单参数冗余这样即使用户之后删号或商品下架订单仍能追溯。状态字段0到5分别代表待支付、已支付、生产中、已发货、已完成、已取消状态机在代码里控制。4.4 支付回调异步通知是个黑匣子状态机要自己守住支付回调是系统里最让人头痛的一环支付网关通知你的服务器“支付成功”这个通知可能延迟、重复、甚至丢失。所以订单状态流转必须幂等回调处理函数里要判断当前状态如果已经是“已支付”直接返回成功不能再把状态重置一遍。public synchronized boolean handlePayCallback(String orderNo) { Order order orderMapper.findByOrderNo(orderNo); if (order null) return false; if (order.getStatus() 1) return true; if (order.getStatus() ! 0) return false; order.setStatus(1); return orderMapper.updateStatus(order) 0; }逻辑说明这个方法是synchronized防止并发回调同时进入先查订单状态为0才能流转到1已支付直接返回成功保证幂等。常见做法是收到回调先验签然后改状态再触发后续的“生产中”流程。回调验签放在最前面验签失败直接拒绝。查询订单接口也要包一层安全校验防止别人用订单号遍历用户信息。5. 常见问题与避坑部署和跑通流程中踩过的五个坑5.1 上传图片后导出失败Canvas被跨域图片污染现象用户上传的图片在画布上看着正常但一执行canvas.toDataURL()就抛SecurityError导出按钮直接失效。原因浏览器安全策略规定如果canvas里绘制了跨域图片且图片没通过CORS合法加载canvas就被标记为“被污染”禁止读取像素数据。很多图床默认不带Access-Control-Allow-Origin头drawImage画进去就脏了。解决上传图片走自己的服务器或OSS并且域名要配CORS前端在Image对象加载前设置img.crossOrigin anonymous服务器返回CORS头两者缺一不可。如果图床已经挂了跨域图且没法改就用canvas.toBlob配合后端转存绕开导出这一步增加系统复杂度但能应对个别素材源。5.2 导出图放大就糊分辨率与离屏Canvas不匹配现象导出图片在屏幕上很清晰放大到印花实际尺寸后边缘全是锯齿印出来没法看。原因直接把屏幕画布的像素导出没有按300DPI重新创建离屏画布。屏幕画布一般只有800乘1000像素放到10英寸乘12英寸的印花区域实际密度只有80DPI左右自然模糊。解决按本章3.4的exportPrintImage思路单独创建一块3000乘3600的离屏画布把设计JSON里的坐标和字号按比例放大重绘。注意文字层放大时要按字号比例重新设置font属性不能简单scale整个画布因为canvas的scale会改变笔画边缘渲染方式导致文字发虚。5.3 换台电脑字体就变字体子集与转曲现象设计时用A字体导出预览正常但过几天再登录画布上的文字变成了默认字体或者印刷出的效果跟设计时完全不同。原因字体文件没有随设计稿一起保存用户浏览器重新加载时字体还没就绪canvas直接用fallback字体渲染。解决前端设计器内置的字体文件要允许跨域加载并在画布初始化时优先await加载必要的字体导出时如果印刷厂要求字体不变形可以在导出PDF前把文字转成曲线路径就是把每个字渲染成矢量轮廓彻底摆脱字体依赖。我的做法是保存设计稿JSON时同时记录fontFamily和字体文件版本号二次编辑时按版本号去匹配字体版本不一致时主动提示用户选择替代字体而不是悄悄fallback。5.4 屏幕色和实物色差别太大RGB到CMYK那一步现象用户在屏幕上选的亮红色印在T恤上变成了暗红色或者大面积色块出现明显色差客户投诉。原因屏幕显示是RGB加色模式T恤印刷是CMYK减色模式两套色彩空间的色域本身就不一致。亮红色在RGB里可以很鲜艳但在CMYK里受油墨限制会变暗。解决设计器里尽量内置一套“限制色域”的预设色板把RGB值限定在CMYK可表达的范围内下单页做一段软打样提示告知用户屏幕色与实物有色差不能完全一致。批量印刷的订单可以跟印刷厂要一版Pantone专色色卡作为参照把色号标注在订单备注里。这个环节做不到百分百一致能做的是把预期偏差提前告知用户管理好心理预期。5.5 手机上画布白屏iOS的Canvas尺寸上限现象设计页在电脑上一切正常用户用iPhone打开时画布区域白屏页面其他部分正常刷新偶尔能恢复。原因iOS Safari对canvas最大面积有限制当你创建的canvas宽度乘高度超过一定像素值某些系统版本在1600万像素左右canvas会直接变成空白不报错也不崩溃非常隐蔽。解决设计器在移动端使用单独的缩配置canvas尺寸降到手机屏幕适配的小画布导出高清图时在桌面端处理或者后端异步渲染。移动端的核心是交互流畅导出任务丢给后端不要在手机浏览器里做3000乘3600的大画布重绘。这个问题的排查思路是PC正常、特定机型白屏优先怀疑canvas面积上限把canvas.width和height分别打印出来对比一下阈值。6. 进阶从单件DIY到小批量印刷对接把T恤DIY定制系统从“在线玩画画”升级到“真能批量生产”最关键的是导出印刷文件时要符合印刷厂的规范。常见的印刷厂接收文件要求是透明背景PNG、300DPI、CMYK色彩模式、预留出血位、单独提供白墨层。白墨层尤其重要深色T恤上印浅色图案必须先印一层白色打底否则浅色图案会被布料颜色吃掉。很多DIY系统翻车就翻在这设计稿导出的是单层RGBA图下单10件深色T恤印出来全是“半透明”效果。我的做法是在导出流程里增加一个“图层分组”概念用户设计时把图案拆成“彩色层”和“白底层”两组白底层是深色衣服的底色填充区域彩色层是实际的图案。导出时分别输出color.png和white.png两个文件白底层自动扩展一圈作为出血。系统在订单详情页生成文件清单印刷厂按单下载两图叠印。这样省去印刷厂自己拆层的沟通成本返工率会明显下降。同一设计多件拼版也是一个细节批量订单10件以上时相同设计可以生成拼版PDF把多个印花区域排在一张大版面上节省印刷厂的排版时间。拼版算法不复杂核心是把每个印花区域按实际尺寸铺到一张大纸上手动调间距防止重叠。我现在的习惯是每次上线前都用一件纯色T恤的真实印样做一次全流程测试从设计、下单、导出到印刷亲自用眼睛验证色差和清晰度。代码跑通不算完印出来没问题才算数。定制系统的本质是“设计体验印刷还原”两段都要硬缺一环后面都要填坑希望帮到你少走这些弯路。本文还有配套的精品资源点击获取