简介：这份资源是面向移动端用户的T恤在线DIY定制系统源码包，适合具备HTML、CSS与JavaScript基础、希望练习canvas绘图与交互设计的前端学习者，也适用于想搭建个性化定制平台的开发者参考。压缩包约14.19MB，内含index.html主入口页面、images模板与设计素材、js交互逻辑脚本、fonts字体文件及css样式表，分别承担页面结构、素材支撑、绘图与操作逻辑、文字样式和视觉布局等职责，目录划分清晰便于按模块阅读。已有797人学习下载，说明其在同类练手项目中具备一定参考价值。读者可从中了解canvas绘制图案与文字合成的实现思路，尤其是文字尚未写入canvas这一待完善点，为后续处理文字与图形合并、保证设计效果一致性提供了明确的改进方向，也可借鉴其素材组织与交互流程设计。
1. 拿到一个 T 恤 DIY 定制系统压缩包，先别急着解压
上周有个做电商的朋友甩过来一个t恤diy定制系统.zip，说客户要一个能在网页上换颜色、换图案、加文字的 T 恤定制页，预算不高，问我这套源码能不能直接改改上线。我打开看了一眼，典型的「前端画布交互 + 图案素材管理 + 订单参数落库」三段式结构，不是那种只能看不能跑的演示壳子。这类 t恤diy设计 资源的价值不在代码多漂亮，而在于它把「用户拖拽图案到衣服上、实时预览、最后把定制参数提交给后端」这条链路完整走通了。适合谁？适合接中小电商定制需求的外包、想快速搭一个 t恤diy源码 原型验证交互的产品，以及需要理解 t恤设计交互 里坐标换算和图层管理的新手。下面按我实际拆包的顺序讲，从目录结构到跑起来，再到改图案和避坑。
2. 拆包看结构：这套 t恤diy系统 到底由哪几块拼起来
解压之后别急着找 index.html 双击打开，先花五分钟把目录摸清楚，后面改代码能省一半时间。这类定制系统的目录通常不会太深，但文件职责分得很开，认错了入口文件是新手最常见的翻车点。
2.1 目录分层与入口文件定位
我拿到的这个包，根目录下大致是这么几层：assets/放 T 恤底图、图案素材和字体；css/是样式；js/里再分lib/（第三方库，通常是 Fabric.js 或 Konva 这类画布库）和业务脚本；index.html是定制页入口；有的包还会带一个api/或server/目录放提交订单的示例后端。判断入口很简单：找那个引用了画布库、又初始化了 canvas 元素的 HTML 文件，一般就是index.html或design.html。
先跑一条命令把结构列出来，比在文件管理器里点来点去快：
# 只看两层目录，过滤掉 node_modules 这类噪音 find . -maxdepth 2 -type d -not -path "*/node_modules*" | sort # 找所有 HTML 入口，确认哪个是定制页 grep -rl "canvas" --include="*.html" .第一条命令给你目录骨架，第二条命令直接锁定含 canvas 的页面。逻辑说明：-maxdepth 2防止目录太深刷屏，grep -rl只输出文件名不输出内容，避免一屏全是 HTML 标签。参数上，如果你的包带了dist/构建产物，记得把dist也加进排除，否则会看到两份重复结构，容易改错文件。
2.2 画布库选型：为什么这类系统偏爱 Fabric.js
打开js/lib/看一眼，十有八九是 Fabric.js。这不是玄学，是这类 t恤设计交互 场景的刚需决定的：用户要拖图案、缩放、旋转、加文字，还要能选中某个元素单独调，原生 Canvas 这些全得自己写命中检测和变换矩阵，工作量翻几倍。Fabric.js 把这些封装成了对象模型，一个fabric.Image就是一个可操作图层，选中、变换、序列化都是现成的。
对比一下常见选择，你就明白为什么这套源码这么搭：
| 方案 | 适合场景 | 在这套系统里的短板 |
|---|---|---|
| 原生 Canvas | 纯展示、粒子动画 | 图层选中、拖拽变换全要手写 |
| Fabric.js | 图形编辑器、定制设计 | 包体积偏大，但功能对得上 |
| Konva.js | 高性能舞台、游戏化交互 | 同样能用，生态略偏动画 |
| DOM + CSS 变换 | 简单贴图、元素少 | 图案多了性能塌，导出成图麻烦 |
我一般会先确认js/lib/里到底是哪个库，因为后面所有改图案、改导出逻辑的写法都跟它绑定。如果是 Fabric.js，业务脚本里一定会有new fabric.Canvas(...)这样的初始化；如果是 Konva，则是new Konva.Stage(...)。认错了库，后面照着改代码全是白费。
2.3 素材与配置：底图、图案、打印区域的约定
定制系统的核心数据其实就三样：T 恤底图（正面/背面）、可打印区域（一个矩形范围，超出就不该让图案跑出去）、图案素材列表。这些通常不会硬编码在 JS 里，而是放在一个config.js或data/下的 JSON 里。找到它，你才知道换一件衣服、加一批图案要改哪里。
常见做法是配置里写死底图路径和打印区坐标，图案列表则是一个数组，每项带id、src、name。我拆的这个包，打印区是用相对底图的百分比坐标存的，好处是换分辨率不用重算，坏处是缩放时容易算错边界，这个坑后面第 4 章会专门讲。先把配置文件找出来读一遍：
# 找配置类文件，JSON 和 js 都扫 find . -iname "*config*" -o -iname "*.json" | grep -v node_modules看到配置后重点确认三件事：底图尺寸是多少像素、打印区矩形相对底图的偏移、图案素材的目录约定。这三样对上了，后面拖拽和导出才不会错位。
3. 把系统跑起来：本地起服务与首次交互验证
结构清楚了就该让它动起来。这类系统有个硬性前提：不能直接双击 HTML 打开。因为画布要加载本地图片素材，file://协议下浏览器会因跨域策略拒绝读取像素数据，导出成图那一步直接报错。血泪经验，第一次拆包我图省事双击打开，拖图案正常，一点「生成预览」就白屏，排查半天才发现是协议问题。
3.1 起一个静态服务再访问
最省事的是用 Python 自带的 HTTP 服务，不用装任何东西：
# 在项目根目录执行，8000 端口起静态服务 python3 -m http.server 8000 # 然后浏览器访问 http://localhost:8000/index.html逻辑说明：http.server把当前目录当网站根目录，所有相对路径引用都能正常解析，图片加载走的是 http 协议，画布读取像素不会被拦。参数上，8000 被占用就换 8080，别用 80 除非你有权限。如果你的包带了package.json和构建脚本，那更规范的做法是先npm install再npm run dev，但很多这类下载包并不带完整构建链，静态服务反而最稳。
起来之后按这个顺序验证，别一上来就乱点：
- 页面能正常显示 T 恤底图，说明素材路径没断。
- 点图案列表里的某个图案，能出现在衣服上，说明素材加载和画布初始化正常。
- 拖动图案、缩放、旋转，选中框跟着走，说明交互层没问题。
- 加一行文字，能改颜色和字号，说明文字图层可用。
- 点导出或提交，能拿到一张合成图或一段参数 JSON，说明整条链路通了。
哪一步卡住，问题范围就缩到那一块，比漫无目的地翻代码高效得多。
3.2 读懂初始化代码：画布尺寸与打印区约束
跑通之后打开业务脚本，找到画布初始化那段。这是整个 t恤diy系统 的地基，尺寸和约束都在这儿定。典型写法长这样：
// 初始化画布，尺寸通常跟底图显示尺寸一致 const canvas = new fabric.Canvas('c', { width: 500, height: 600, preserveObjectStacking: true // 选中时图层不跳到最顶，方便调层级 }); // 打印区约束：图案移动时限制在矩形内 const printArea = { left: 150, top: 120, width: 200, height: 260 }; canvas.on('object:moving', (e) => { const obj = e.target; // 把对象边界钳制在打印区内，超出就拉回 obj.set({ left: Math.max(printArea.left, Math.min(obj.left, printArea.left + printArea.width - obj.getScaledWidth())), top: Math.max(printArea.top, Math.min(obj.top, printArea.top + printArea.height - obj.getScaledHeight())) }); });逻辑说明：preserveObjectStacking这个参数很关键，不开的话你点中底层图案它会自动跳到最上层，调完层级全乱，用户会以为系统有 bug。object:moving事件里做边界钳制，用的是对象缩放后的实际宽高getScaledWidth()，不是原始宽高，这点新手极容易写错——用原始宽高的话，图案一放大就会跑出打印区。参数上，printArea的四个值要跟你的底图实际打印位置对齐，换衣服款式必须重算，不能照抄。
3.3 图案加载与图层顺序的默认行为
再往下看图案是怎么加进画布的。一般是点素材列表触发一个函数，fabric.Image.fromURL加载图片后canvas.add。这里有个默认行为要留意：后加的对象在上层。如果系统没做层级管理，用户先加文字再加图案，图案会盖住文字，看起来像文字丢了。合格的实现会在加对象时给个固定层级策略，比如图案永远在文字下面，或者提供「上移/下移」按钮。
我拆的这套带了简单的层级按钮，但默认顺序是「谁后加谁在上」，这就埋了个坑：用户先排版文字再贴图案，图案压住文字，导出后文字被挡。改法是在canvas.add之后调obj.sendToBack()或维护一个zIndex映射，具体看你的业务约定。这一步不复杂，但不改的话上线必被投诉。
4. 改图案、换底图、调打印区：三个高频改动点
跑通只是起点，真正交付前客户一定会让你换衣服、换图案、调可印范围。这三件事看着简单，每件都有边界条件，改错一个就白干。
4.1 替换图案素材与缩略图同步
换图案素材最直接：把新图丢进assets/patterns/，然后在配置数组里加一项。但很多人只加了配置，忘了缩略图。素材列表页显示的往往是小图，如果配置里thumb字段还指向旧路径或干脆没写，列表就出现裂图。常见做法是缩略图和原图分开存，缩略图控制在 100×100 以内，加载快；原图保持高清，导出时才用。
// 图案配置项的标准结构，thumb 和 src 分开 const patterns = [ { id: 'p001', name: '几何图形', thumb: 'assets/patterns/thumb/p001.png', // 列表展示用 src: 'assets/patterns/full/p001.png' // 上画布用 } ];逻辑说明：列表渲染只读thumb，点击后才用src加载到画布，这样首屏不会因为加载一堆高清图而卡顿。参数上，src的图片建议控制在 1000px 以内，太大拖拽会掉帧；透明背景的 PNG 是必须的，JPG 贴上去会带白底，这是新手最常犯的错。
4.2 换底图后打印区坐标的重算
换一件不同版型的 T 恤，底图尺寸变了，打印区坐标必须跟着重算。我见过有人直接沿用旧坐标，结果图案印到袖子上。正确做法是拿新底图的实际像素尺寸，按比例换算打印区。假设旧底图 500×600、打印区left:150, top:120, width:200, height:260，新底图 600×720，等比放大 1.2 倍，四个值全部乘 1.2。
// 按底图缩放比例重算打印区，避免手算出错 function scalePrintArea(base, ratio) { return { left: base.left * ratio, top: base.top * ratio, width: base.width * ratio, height: base.height * ratio }; } // 旧底图 500 宽，新底图 600 宽，比例 1.2 const newArea = scalePrintArea({ left: 150, top: 120, width: 200, height: 260 }, 600 / 500);逻辑说明：用比例函数而不是手算，换多件衣服时不容易漏。参数上，比例取新底图宽除以旧底图宽，前提是两件衣服版型比例一致；如果版型差异大（比如修身换宽松），光等比缩放不够，得按实际打印位置重新标定，这一步没有捷径，只能对着底图量。
4.3 导出合成图的分辨率与格式取舍
最后交付给后端或打印厂的，通常是一张合成图。导出这块的取舍很实际：分辨率低了打印糊，高了文件大、生成慢。常见做法是按打印实际物理尺寸反推像素，比如 A4 区域 300dpi 约 2480×3508，但 T 恤打印区没这么大，2000px 宽基本够用。
// 导出时用 multiplier 放大，而不是改画布尺寸 const dataURL = canvas.toDataURL({ format: 'png', multiplier: 2 // 画布 500 宽，导出 1000 宽 });逻辑说明：multiplier是在导出瞬间按倍数渲染，不影响用户看到的画布尺寸，比直接调大画布再缩显示要干净。参数上，format选 png 保留透明，选 jpeg 要传quality（0.9 左右），但 jpeg 不支持透明，图案边缘会有白边，定制场景基本都用 png。导出后记得把 dataURL 转成 Blob 再上传，直接传 base64 字符串体积会膨胀约三分之一。
5. 避坑与排查：这套 t恤diy源码 最容易翻车的五个地方
下面这几条都是我实际改这类系统时踩过的，按「现象 → 原因 → 解决」写，照着对号入座能省不少时间。
现象一：拖图案时图案跑出衣服范围，松手又弹回。原因多半是边界钳制只写了object:moving，没处理object:scaling和object:rotating，缩放和旋转时对象尺寸变了，钳制逻辑没跟上。解决：把钳制逻辑抽成一个函数，三个事件都绑上，且用getScaledWidth()而不是width。
现象二：导出图里图案位置和画布上看到的对不上。原因是画布显示尺寸和导出 multiplier 之间，有人手动改过canvas.setDimensions，导致坐标基准变了。解决：导出前不要动画布尺寸，统一用multiplier放大；如果必须改，改完要重新校准所有对象的left/top。
现象三：换底图后图案全部偏移。原因是底图换了但画布width/height没同步，或者打印区坐标没按比例重算。解决：换底图时把画布尺寸、打印区、背景图三者当成一个整体一起改，写个loadTemplate()函数统一处理，别东改一处西改一处。
现象四：图案列表点多了页面越来越卡。原因是每次点击都fabric.Image.fromURL重新加载，没有缓存，且旧对象没清理。解决：加载过的图片存进一个Map缓存，重复点击直接复用；切换图案时先canvas.remove旧对象再add新的，别只 add 不 remove。
现象五：移动端手指拖拽和页面滚动打架。原因是画布没禁用触摸默认行为，手指拖图案时页面跟着滚。解决：给 canvas 容器加touch-action: none，并在 Fabric 初始化时设allowTouchScrolling: false，两者配合才能让拖拽只作用于图案。
提示：排查这类交互问题，优先在浏览器控制台看有没有报错，再看事件有没有绑上。很多「没反应」其实是 JS 报错中断了后续绑定，不是逻辑写错。
6. 进阶：把定制参数结构化落库，而不是只存一张图
只导出图片是不够的。真正要复用的定制系统，得把「用户选了什么底图、贴了哪些图案、每个图案的坐标缩放旋转、加了什么文字」存成结构化数据，图片只是渲染结果。这样后端才能重新渲染、换分辨率出图、甚至做二次编辑。我一般会在导出时同时生成两份东西：一份合成图给预览，一份 JSON 参数给后端。
// 导出结构化参数，只保留可复现的必要字段 function exportDesign(canvas) { const objects = canvas.getObjects().map((obj) => ({ type: obj.type, // image / text / i-text src: obj.type === 'image' ? obj.getSrc() : null, text: obj.type !== 'image' ? obj.text : null, left: obj.left, top: obj.top, scaleX: obj.scaleX, scaleY: obj.scaleY, angle: obj.angle, fill: obj.fill || null })); return { templateId: 'tshirt-front', objects }; }逻辑说明：getObjects()拿到所有图层，按类型分别取图片路径或文字内容，坐标和变换参数原样保留。参数上，templateId用来标记当前是哪件衣服的哪一面，后端靠它找对应底图和打印区重渲染。这份 JSON 体积很小，存数据库毫无压力，比存 base64 图片省得多。
验证方法也简单：拿导出的 JSON，写个脚本重新fabric.Image.fromURL和new fabric.IText逐个还原，对比还原图和原导出图，像素级对不上就说明有字段漏了。我习惯在每次改完导出逻辑后跑一遍这个还原对比，比肉眼检查靠谱。
从那以后我每次接这类定制系统，都强制先跑一遍「导出 JSON → 还原 → 对比」这条闭环，再谈换素材和调样式。很多看起来正常的交互，一还原就暴露坐标基准或图层顺序的问题。希望这套拆包思路帮到你，拿到压缩包能少走几步弯路。
本文还有配套的精品资源，点击获取
