简介：面向手机端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版本。版本不对，后面编译报错会浪费大量时间。
运行环境确认表：
| 组件 | 版本要求 | 说明 |
|---|---|---|
| JDK | 1.8及以上 | 过低版本无法运行Spring Boot 2.x |
| MySQL | 5.7及以上 | 设计图层JSON字段需要utf8mb4支持 |
| Node.js | 14及以上 | 前端画布依赖新版浏览器特性 |
| Maven | 3.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把文件读成base64，Image对象加载后计算缩放比例，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，但不要低于150；printWidthInch和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恤的真实印样做一次全流程测试，从设计、下单、导出到印刷，亲自用眼睛验证色差和清晰度。代码跑通不算完，印出来没问题才算数。定制系统的本质是“设计体验+印刷还原”，两段都要硬，缺一环后面都要填坑，希望帮到你少走这些弯路。
本文还有配套的精品资源，点击获取
