做服装类电商系统一直是很多开发者练手的热门方向，一是业务链路完整，从前台展示到购物车、订单、支付模拟，一套流程下来基本覆盖了常见业务系统的核心场景；二是前后端分离模式在真实项目中用得最普遍，学完直接能对标公司里的开发模式。“衣依”就是这个定位下的一个典型项目：Java SpringBoot+Vue3+MyBatis+MySQL，前后端完全分离，代码结构清晰，非常适合想搞懂电商业务闭环、或者准备做课程设计/毕设/面试项目的朋友。这篇博文我会把这个项目的设计思路、数据库建模、后端核心逻辑、前端页面联调、本地部署和避坑经验一次性讲透，全部基于我可以直接复现的实践经验来写。1. 项目整体定位与技术选型拆解1.1 为什么是SpringBoot+Vue3+MyBatis这套组合？先说技术栈的选型逻辑。市面上做电商系统可以选的技术组合很多，比如SpringCloud微服务、Python Django、Go Gin等等，但这个项目用“SpringBoot+Vue3+MyBatis”这套经典组合，其实是充分考虑到了“规模”和“学习成本”的匹配。SpringBoot的优势不用多说，它把Spring大量繁琐的XML配置全部自动化了。对于服装销售平台这种单体应用来说，SpringBoot内置Tomcat，起步就是mvn spring-boot:run，不用单独部署Web容器，开发效率非常高。尤其是我这种习惯“先跑起来再改”的开发者，SpringBoot的自动配置能在十分钟内把项目骨架搭好。前端选Vue3是自然的趋势。Vue3的组合式API（Composition API）在逻辑复用和代码组织上比Vue2的选项式API更适合中大型页面。衣依项目里商品列表、购物车、个人中心这些页面之间有大量共享状态（比如购物车数量、用户登录态），用组合式API配合状态管理库，逻辑会清楚很多。MyBatis作为持久层框架，它跟SpringBoot的兼容性极好，核心思路就是“SQL由开发者自己控制”。电商系统里有大量复杂查询，比如商品多条件筛选、订单明细联查、报表统计，MyBatis能让我们对SQL有完全的掌控力，不会像JPA那样在复杂查询时被迫生成低效语句。当然代价是要手写不少XML或注解SQL，但这本身就是学习数据库和SQL的好机会。1.2 服装销售平台的业务边界与功能模块划分在动手写代码之前，我一直强调要想清楚业务边界。“衣依”定位是B2C服装销售平台，用户端（前台）和管理端（后台）是两个天然的大模块。前台面向普通消费者，核心流程是：注册登录 -> 浏览商品 -> 分类筛选 -> 查看详情 -> 加入购物车 -> 提交订单 -> 模拟支付 -> 查看订单状态。围绕这条主链，还应该有个人中心（收货地址管理、订单查询）、商品搜索、商品收藏等功能。后台面向管理员，核心职责是：商品管理（上架/下架/编辑）、分类管理、订单管理（发货/查看明细）、用户管理、轮播图管理。后台不需要太复杂，但所有对商品和订单的写操作必须完整，能支撑前台业务流转起来。注意，这里有两个在需求阶段就要确定的点：第一，支付环节做的是“模拟支付”——用户点击支付按钮后直接将订单状态置为已支付，不接任何真实支付渠道，这是绝大多数学习型项目的合理取舍；第二，商品不考虑SKU（比如颜色尺码组合），以单规格商品建模。如果想扩展SKU，需要另建商品规格表，这个我在后面会提到。2. 数据库设计：服装电商领域的建模关键点2.1 核心表结构与实体关系梳理“衣依”数据库我按业务域拆成了用户域、商品域、交易域、营销域四部分。其中核心表给大家列一下：member用户表：id、username、password、nickname、avatar、phone、status、create_timeaddress收货地址表：id、member_id、receiver_name、receiver_phone、province、city、district、detail、is_defaultcategory商品分类表：id、parent_id、name、icon、sort、statusproduct商品表：id、category_id、name、subtitle、main_image、detail、price、stock、sales、status、create_timeproduct_image商品图片表：id、product_id、url、sortcart购物车表：id、member_id、product_id、quantity、checked、create_timeorders订单表：id、order_no、member_id、address_id、total_amount、pay_amount、pay_type、status、receiver_info（收货信息快照）、create_time、pay_time、ship_time、finish_timeorder_item订单明细表：id、order_id、product_id、product_name、product_image、product_price、quantity、total_pricecollect收藏表：id、member_id、product_id、create_timecomment评论表：id、member_id、product_id、content、rating、create_timebanner轮播图表：id、image、url、sort、status从关系上看，category对product是一对多，member对orders和cart是一对多，orders对order_item是一对多。address挂在用户下面，每次下单时从用户地址列表里选一个。建表时我给所有表都加了create_time和update_time，虽然增加了一点写入负担，但排查问题时非常有用，强烈建议保留。另外所有金额字段用decimal(10,2)，数量字段用int，库存字段不允许负数——这个在MySQL里可以加CHECK约束，但更靠谱的还是代码层面扣库存前先判断。2.2 订单明细里为什么要存“商品快照”这是整个数据库设计里我特别想强调的一点。订单明细表（order_item）里除了product_id外，还冗余存储了product_name、product_image、product_price这几个字段。很多初学者不理解：为什么不直接通过product_id去关联查询商品表？因为在真实电商场景中，商品不是永恒不变的。一件衣服可能改价、可能改名、可能下架，但用户的历史订单是不能被这些变更影响的。用户下单时买的是“79元的那件衬衫”，三个月后商家把价格改成99元，如果订单明细直接关联商品表，用户查看历史订单时看到的就会是99元，这就会引发纠纷，甚至涉及法律层面的电子凭证问题。用“快照”的方式，把下单那一刻的商品名称、图片、单价、数量冗余存储到订单明细里，订单就成了不可变的历史事实。这也是为什么理论上订单明细可以不关联商品表，只保留product_id用于反查。我的建议是页面展示优先读取快照字段，product_id仅作为关联查询入口。2.3 订单状态机与事务一致性设计订单状态是整个交易链路的核心，我在设计时用tinyint类型的status字段来标识，含义如下：状态值含义场景说明0待支付订单已创建，用户尚未完成模拟支付1待发货（已支付）模拟支付成功后2待收货（已发货）管理员在后台点击发货后3已完成用户确认收货或系统自动确认4已取消用户主动取消或超时未支付状态流转在代码里是严格单向的，不允许从待支付直接跳到已完成。我在Service层定义了一个orderStatusChange的方法，内部通过synchronized锁或者数据库乐观锁（update ... where status = ?）保证并发场景下的状态正确性。事务一致性的重点在于“下单减库存”这个动作。异常情况有两大类：一是用户疯狂点击提交订单按钮导致重复下单；二是多个用户同时购买同一件库存只剩1件的商品。我的处理方案是：在orders表里用唯一订单号（order_no）做防重，在扣库存的SQL里加上WHERE stock >= quantity的条件，受影响行数为0说明库存不足，直接抛异常回滚。整个下单方法打上@Transactional，任何一个环节出错，订单和库存数据都能恢复到操作前状态。3. 后端SpringBoot核心实现解析3.1 工程目录结构与统一响应模型后端工程我习惯按“Controller-Service-Mapper”三层划分，包名按模块组织，和普通公司项目保持一致。目录结构大致是这样：com.yiyi ├── common // 全局异常、统一结果、常量、工具类 ├── controller // 接口层：ProductController、OrderController等 ├── service // 业务层：接口+实现类 ├── mapper // MyBatis的Mapper接口 ├── entity // 数据库实体类（与表字段一一对应） ├── dto // 前端传输对象（接收参数和返回视图对象） ├── config // 配置类：跨域、拦截器、MyBatis-Plus相关配置统一响应对象是前后端分离项目的基石。如果没有它，每个接口返回的字段结构就会五花八门，前端完全没法写统一的处理逻辑。我在common包里定义了一个Result类：public class Result<T> { private Integer code; // 200成功 500失败 401未登录 private String message; private T data; public static <T> Result<T> success(T data) { ... } public static <T> Result<T> error(String message) { ... } }配合全局异常处理器@RestControllerAdvice，service层一旦抛出BizException（自定义业务异常），前端能收到结构一致的错误响应。我一直认为这部分代码虽然看起来“不起眼”，但它决定了前后端联调时是事半功倍还是事倍功半。3.2 商品查询：分页+多条件筛选的实现商品列表页是用户进入系统后最先接触的页面，对查询接口的要求是：支持分类筛选、商品名模糊搜索、价格排序、分页加载。我直接在Mapper层写动态SQL，用<where>标签和<if>标签来拼条件：<select id="selectProductPage" resultType="com.yiyi.entity.Product"> SELECT * FROM product <where> status = 1 <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> AND name LIKE CONCAT('%', #{keyword}, '%') </if> </where> <choose> <when test="sort == 'price_asc'">ORDER BY price ASC</when> <when test="sort == 'price_desc'">ORDER BY price DESC</when> <otherwise>ORDER BY id DESC</otherwise> </choose> </xml>分页我用的是MyBatis的分页插件PageHelper，调用方式极其简单：在查询前执行PageHelper.startPage(pageNum, pageSize)，紧接着的第一次SQL查询就会自动拼接LIMIT，同时会生成一个PageInfo对象，里面包含total、pages、list等分页数据。这里有个经验之谈：PageHelper的startPage只对紧跟着的第一个查询生效，所以如果查询前要先做别的操作（比如先查分类再查商品），就会导致分页失效甚至报错。我在页面加载时要同时返回分类列表和商品列表，就拆成了两个独立接口，前端并行请求，完美避开这个坑。3.3 购物车下单与库存扣减的核心流程下单接口是“衣依”系统里业务逻辑最集中的地方，核心Service方法我来拆解一下整体流程：@Transactional public OrderVO submitOrder(OrderSubmitDTO dto) { // 1. 校验用户登录态并获取收货地址 Address address = addressMapper.selectByPrimaryKey(dto.getAddressId()); if (address == null) throw new BizException("收货地址不存在"); // 2. 根据购物车ID列表查询所有勾选商品 List<CartItem> cartItems = cartMapper.selectCheckedItems(dto.getMemberId()); // 3. 逐一校验商品状态和库存 for (CartItem item : cartItems) { Product product = productMapper.selectByPrimaryKey(item.getProductId()); if (product.getStatus() != 1) throw new BizException("商品已下架"); if (product.getStock() < item.getQuantity()) throw new BizException("商品库存不足"); } // 4. 生成唯一订单号并创建订单主记录 String orderNo = "YY" + System.currentTimeMillis() + RandomUtil.randomNumbers(4); // 计算总金额，写入订单表（含收货信息快照） // 5. 生成订单明细快照，同时扣减库存 for (CartItem item : cartItems) { Product product = productMapper.selectByPrimaryKey(item.getProductId()); orderItemMapper.insert(...); // 存入商品名、图片、价格快照 int rows = productMapper.reduceStock(item.getProductId(), item.getQuantity()); if (rows == 0) throw new BizException("库存扣减失败"); } // 6. 清空已下单的购物车 cartMapper.deleteByIds(...); return buildOrderVO(order); }整个方法只有@Transactional一个注解，但数据库事务却做了四件事：插订单、插明细、扣库存、清购物车。一旦中间任何一步失败，全部回滚，不会出现“订单创建了但库存没减”或者“库存减了但购物车没清”的数据不一致问题。这里再补充一个细节：模拟支付接口做的事其实特别简单，就是校验订单属于当前用户且状态为待支付，然后UPDATE orders SET status = 1, pay_time = NOW() WHERE order_no = ? AND status = 0，受影响行数为1即支付成功。用条件更新可以再次防止并发下的状态错误。3.4 登录鉴权：JWT还是Session？“衣依”作为前后端分离项目，登录态管理最合适的方案是JWT。服务器的处理逻辑是：用户登录成功后，用userId和username生成一个带过期时间的token，返回给前端；前端每次请求在Authorization头里带上token；后端通过拦截器（HandlerInterceptor）统一解析，未登录请求直接返回401。public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || !JwtUtil.verify(token)) { // 返回401并写出Result对象 return false; } // 从token中取出userId放入request request.setAttribute("userId", JwtUtil.getUserId(token)); return true; } }注册登录的密码存储我用了MD5加盐处理，虽然现在更推荐BCrypt，但对于学习项目用MD5+固定盐也够演示。拦截器放行规则要注意：商品查询、分类查询、首页轮播图这些公开接口必须放行，涉及个人中心、购物车、下单的接口必须拦截。另外要处理一个容易忽略的问题：用户下单、查看订单时，后端绝不能直接信任前端传来的userId，而必须从token解析出来的用户身份为准，否则就会出现“水平越权”漏洞。我在“衣依”里所有订单查询方法都强制带上前端传的memberId和token里的userId做二次比对。4. 前端Vue3实现与联调关键点4.1 前端工程结构与状态管理前端使用Vite作为构建工具，目录和组件划分如下：src ├── api // 接口请求封装（按模块拆分） ├── router // 路由配置与守卫 ├── store // 状态管理（用户信息、购物车数量） ├── views // 页面组件 │ ├── Home.vue // 首页 │ ├── ProductList.vue // 商品列表 │ ├── ProductDetail.vue │ ├── Cart.vue // 购物车 │ ├── OrderConfirm.vue │ ├── OrderList.vue │ ├── Login.vue │ └── UserCenter.vue └── components // 公共组件（Header、Footer、商品卡片等）状态管理选择上我用了Pinia，比Vuex更简洁且对TypeScript更友好。用户登录成功后会同时把token和用户基本信息存进Pinia，并用localStorage做持久化，刷新页面后还能保持登录状态。另外购物车角标的数量我单独放在一个useCartStore里，每次增删购物车后都会重新拉取数量，保证Header展示的角标和实际数据一致。路由守卫是前端鉴权的重要一环：在router.beforeEach里检查要访问的页面是否需要登录（通过路由meta字段标记），如果未登录则跳转到登录页，登录成功后通过redirect参数回到原页面。这个体验细节很加分。4.2 首页、商品列表与购物车交互首页一般由轮播图、分类导航、热门商品几个区域组成。我把首页看作一个“组合页面”，通过几个子组件拼装，数据统一在Home.vue里通过onMounted并发请求三个接口加载。这样页面加载最快，每个接口独立loading，一个接口失败不会影响其他区域展示。商品列表页是重点，用户通过顶部导航或首页分类进入。我用了watch监听路由参数categoryId和查询参数keyword的变化，参数一变就重新请求列表数据。分页用的是滚动到底部自动加载更多，而不是传统页码翻页，更符合商城类App的使用习惯。这个用onMounted监听window.scroll事件实现，注意在组件卸载时移除事件监听，避免内存泄漏。购物车页面有一个细节要处理好：勾选商品、修改数量、计算总价都是纯前端状态操作，只有点击“去结算”时才把购物车ID列表提交到后端生成订单。前端实时计算总价用computed依赖购物车项里的checked和quantity，不需要每次点击都请求后端接口，体验非常流畅。4.3 axios封装与开发环境跨域处理前后端分离开发时，前端地址是localhost:5173，后端是localhost:8080，浏览器跨域问题不可避免。我在Vite的配置文件里加了代理：// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, } } } })这样前端请求/api/product/list实际会代理到http://localhost:8080/api/product/list，浏览器不再直接跨域，而后端的跨域配置只是兜底方案。我习惯统一在axios实例里设置baseURL: '/api'，所有接口以/api开头，这样后面如果部署到nginx，也只需要调整nginx的路径转发规则。axios的拦截器做了两件事：请求拦截器把Pinia里的token加到请求头Authorization；响应拦截器只处理Result对象，如果code不为200就弹出提示信息，同时单独处理401（token过期）跳转到登录页。这样业务代码里就不需要反复写错误处理逻辑了。5. 本地部署与运行实操5.1 环境准备与数据库初始化要把“衣依”系统在本地跑起来，需要准备以下基础环境：JDK 1.8或11、Maven 3.6以上、MySQL 5.7或8.0、Node.js 16以上（推荐18）。IDE我个人喜欢用IntelliJ IDEA，前端用VS Code。拿到源码后，第一步是执行项目根目录下的yiyi.sql脚本。里面有建库建表和初始数据，建议直接用命令行或Navicat整体执行。执行完确认数据库yiyi下能看到十几张表和若干条测试数据。项目里自带的测试账号有两个——前台用户账号密码通常是admin/123456，管理端是manager/123456，跑起来后可以直接登录体验。第二步是修改后端application.yml中的数据库连接信息：server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/yiyi?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver这里要特别注意serverTimezone=Asia/Shanghai这个参数。如果省略，国内服务器用默认时区可能会导致时间差8小时甚至启动报错。5.2 后端启动与接口自测后端启动非常简单，在项目根目录执行：mvn spring-boot:run看到“Started Application in xx seconds”日志就代表启动成功。如果Maven下载依赖时速度太慢，可以在~/.m2/settings.xml里配置国内镜像源。接口自测我强烈推荐用Apifox或者直接用Postman。先调一次登录接口获取token，然后测试商品查询、加入购物车、提交订单的接口。注意测试下单前先在数据库里给测试用户添加一条收货地址，不然下单会提示地址不存在。对于“衣依”这种自带Swagger配置的项目，也可以直接访问http://localhost:8080/swagger-ui.html进行可视化接口调试，比纯手写请求体更直观。5.3 前端启动与全流程验证前端在项目前端的目录下执行：npm install npm run dev启动成功后终端会打印Vite的访问地址，一般是http://localhost:5173。首次启动要是遇到npm install报错，优先检查Node版本，Vite3要求Node14.18以上，Vite5要求Node18以上。打开页面后完整走一遍核心流程：注册一个全新账号 -> 首页浏览 -> 进入商品详情 -> 加入购物车 -> 结算下单 -> 模拟支付 -> 在个人中心查看订单。同时用管理端账号登录后台，把订单标记发货，再回到用户端确认收货。这套流程全部走通，就说明前后端所有核心接口都正常了。6. 常见问题排查与实战避坑6.1 启动与运行常见问题速查表问题现象可能原因排查与解决方案后端启动报数据库连接失败数据库没启动 / 账号密码错 / URL里的库名不对先用Navicat测试连接，检查application.yml的三项配置前端启动成功但页面白屏接口全部404或500打开浏览器F12看Network的具体状态码，排查代理配置和后端是否启动登录接口返回401token生成或拦截器逻辑问题检查拦截器放行了登录接口，检查JWT密钥是否一致MyBatis查询出null字段表字段下划线转驼峰未配置在application.yml开启map-underscore-to-camel-case: true时间字段显示为时间戳Jackson序列化配置缺失在application.yml配置时间格式化或使用@JsonFormat注解提交订单报库存不足并发扣减/测试数据库存为0检查reduceStock的SQL是否带stock >= quantity条件前端刷新页面404路由模式为history开发环境用Vite的historyApiFallback，生产环境由nginx配置try_files处理6.2 我踩过的几个坑，给各位提个醒第一个坑是MyBatis的驼峰映射。数据库字段是create_time，实体类属性是createTime，如果不开启驼峰映射，这个字段永远是null。新手很容易排查半天才发现是配置项漏了。我的做法是在application.yml里统一加上：mybatis: configuration: map-underscore-to-camel-case: true第二坑是查询列表时把大字段全查出来了。商品表里有个detail字段存的是很长的HTML详情，如果列表接口SELECT *，不仅传输慢还拖垮渲染。我的做法是列表接口用单独的SQL只查id, name, price, main_image, subtitle，详情接口才查完整字段。这算是很基础但非常实用的性能优化。第三个坑是图片上传后的访问路径。项目里的商品图片是上传到本地磁盘某个目录的，如果上传成功了但页面加载不出图片，八成是上传路径和静态资源映射目录对不上。后端的资源映射配置要指向实际文件目录，否则前端访问不到。最简单的做法是上传接口返回完整的可访问URL，前端直接展示，避免二次拼接出错。第四个坑是前端路由的history模式部署问题。开发环境下一切正常，但打包部署到服务器后，刷新页面除了首页，其他路径全部404。原因是路由切换是前端路由，但刷新时浏览器会以当前路径请求服务器，服务器没有对应的后端路由，自然报404。解决办法是在nginx上配置try_files $uri $uri/ /index.html;，把不存在的路径都fallback到前端入口。这个在项目部署文档里一定要写清楚。第五个坑是删除购物车数据时用foreach逐条删除，性能不好且事务太长。我后来改成了按用户ID和商品ID集合批量删除，一条SQL搞定。类似的批量操作还有订单列表查询，不要用循环查数据库，要学会用IN查询一次取出所有关联数据。做这类项目我最大的体会是：技术本身没有太多高深的东西，真正的难点在于把每个模块间的数据流转理清楚，把边界条件想透。“衣依”这个系统单看代码量不算大，但商品、购物车、订单、库存这些环节串起来后，就是一个小而完整的电商闭环。如果你跟我一样是冲着练手来的，建议拿到源码后先别看实现，自己先画一遍业务流程图和数据表关系图，再对照代码看差异，这样收获会大得多。最后再分享一个扩展方向：这个项目最值得升级的地方是商品SKU管理和优惠券模块。商品表加一个sku表，把颜色、尺码、库存下沉到规格层级；优惠券则牵涉到领取、核销和订单金额计算，能把业务复杂度提升一个档次。把这两块啃下来，你对电商系统的理解会比现在深很多。
做服装类电商系统一直是很多开发者练手的热门方向，一是业务链路完整，从前台展示到购物车、订单、支付模拟，一套流程下来基本覆盖了常见业务系统的核心场景；二是前后端分离模式在真实项目中用得最普遍，学完直接能对标公司里的开发模式。“衣依”就是这个定位下的一个典型项目：Java SpringBoot+Vue3+MyBatis+MySQL，前后端完全分离，代码结构清晰，非常适合想搞懂电商业务闭环、或者准备做课程设计/毕设/面试项目的朋友。这篇博文我会把这个项目的设计思路、数据库建模、后端核心逻辑、前端页面联调、本地部署和避坑经验一次性讲透，全部基于我可以直接复现的实践经验来写。1. 项目整体定位与技术选型拆解1.1 为什么是SpringBoot+Vue3+MyBatis这套组合？先说技术栈的选型逻辑。市面上做电商系统可以选的技术组合很多，比如SpringCloud微服务、Python Django、Go Gin等等，但这个项目用“SpringBoot+Vue3+MyBatis”这套经典组合，其实是充分考虑到了“规模”和“学习成本”的匹配。SpringBoot的优势不用多说，它把Spring大量繁琐的XML配置全部自动化了。对于服装销售平台这种单体应用来说，SpringBoot内置Tomcat，起步就是mvn spring-boot:run，不用单独部署Web容器，开发效率非常高。尤其是我这种习惯“先跑起来再改”的开发者，SpringBoot的自动配置能在十分钟内把项目骨架搭好。前端选Vue3是自然的趋势。Vue3的组合式API（Composition API）在逻辑复用和代码组织上比Vue2的选项式API更适合中大型页面。衣依项目里商品列表、购物车、个人中心这些页面之间有大量共享状态（比如购物车数量、用户登录态），用组合式API配合状态管理库，逻辑会清楚很多。MyBatis作为持久层框架，它跟SpringBoot的兼容性极好，核心思路就是“SQL由开发者自己控制”。电商系统里有大量复杂查询，比如商品多条件筛选、订单明细联查、报表统计，MyBatis能让我们对SQL有完全的掌控力，不会像JPA那样在复杂查询时被迫生成低效语句。当然代价是要手写不少XML或注解SQL，但这本身就是学习数据库和SQL的好机会。1.2 服装销售平台的业务边界与功能模块划分在动手写代码之前，我一直强调要想清楚业务边界。“衣依”定位是B2C服装销售平台，用户端（前台）和管理端（后台）是两个天然的大模块。前台面向普通消费者，核心流程是：注册登录 -> 浏览商品 -> 分类筛选 -> 查看详情 -> 加入购物车 -> 提交订单 -> 模拟支付 -> 查看订单状态。围绕这条主链，还应该有个人中心（收货地址管理、订单查询）、商品搜索、商品收藏等功能。后台面向管理员，核心职责是：商品管理（上架/下架/编辑）、分类管理、订单管理（发货/查看明细）、用户管理、轮播图管理。后台不需要太复杂，但所有对商品和订单的写操作必须完整，能支撑前台业务流转起来。注意，这里有两个在需求阶段就要确定的点：第一，支付环节做的是“模拟支付”——用户点击支付按钮后直接将订单状态置为已支付，不接任何真实支付渠道，这是绝大多数学习型项目的合理取舍；第二，商品不考虑SKU（比如颜色尺码组合），以单规格商品建模。如果想扩展SKU，需要另建商品规格表，这个我在后面会提到。2. 数据库设计：服装电商领域的建模关键点2.1 核心表结构与实体关系梳理“衣依”数据库我按业务域拆成了用户域、商品域、交易域、营销域四部分。其中核心表给大家列一下：member用户表：id、username、password、nickname、avatar、phone、status、create_timeaddress收货地址表：id、member_id、receiver_name、receiver_phone、province、city、district、detail、is_defaultcategory商品分类表：id、parent_id、name、icon、sort、statusproduct商品表：id、category_id、name、subtitle、main_image、detail、price、stock、sales、status、create_timeproduct_image商品图片表：id、product_id、url、sortcart购物车表：id、member_id、product_id、quantity、checked、create_timeorders订单表：id、order_no、member_id、address_id、total_amount、pay_amount、pay_type、status、receiver_info（收货信息快照）、create_time、pay_time、ship_time、finish_timeorder_item订单明细表：id、order_id、product_id、product_name、product_image、product_price、quantity、total_pricecollect收藏表：id、member_id、product_id、create_timecomment评论表：id、member_id、product_id、content、rating、create_timebanner轮播图表：id、image、url、sort、status从关系上看，category对product是一对多，member对orders和cart是一对多，orders对order_item是一对多。address挂在用户下面，每次下单时从用户地址列表里选一个。建表时我给所有表都加了create_time和update_time，虽然增加了一点写入负担，但排查问题时非常有用，强烈建议保留。另外所有金额字段用decimal(10,2)，数量字段用int，库存字段不允许负数——这个在MySQL里可以加CHECK约束，但更靠谱的还是代码层面扣库存前先判断。2.2 订单明细里为什么要存“商品快照”这是整个数据库设计里我特别想强调的一点。订单明细表（order_item）里除了product_id外，还冗余存储了product_name、product_image、product_price这几个字段。很多初学者不理解：为什么不直接通过product_id去关联查询商品表？因为在真实电商场景中，商品不是永恒不变的。一件衣服可能改价、可能改名、可能下架，但用户的历史订单是不能被这些变更影响的。用户下单时买的是“79元的那件衬衫”，三个月后商家把价格改成99元，如果订单明细直接关联商品表，用户查看历史订单时看到的就会是99元，这就会引发纠纷，甚至涉及法律层面的电子凭证问题。用“快照”的方式，把下单那一刻的商品名称、图片、单价、数量冗余存储到订单明细里，订单就成了不可变的历史事实。这也是为什么理论上订单明细可以不关联商品表，只保留product_id用于反查。我的建议是页面展示优先读取快照字段，product_id仅作为关联查询入口。2.3 订单状态机与事务一致性设计订单状态是整个交易链路的核心，我在设计时用tinyint类型的status字段来标识，含义如下：状态值含义场景说明0待支付订单已创建，用户尚未完成模拟支付1待发货（已支付）模拟支付成功后2待收货（已发货）管理员在后台点击发货后3已完成用户确认收货或系统自动确认4已取消用户主动取消或超时未支付状态流转在代码里是严格单向的，不允许从待支付直接跳到已完成。我在Service层定义了一个orderStatusChange的方法，内部通过synchronized锁或者数据库乐观锁（update ... where status = ?）保证并发场景下的状态正确性。事务一致性的重点在于“下单减库存”这个动作。异常情况有两大类：一是用户疯狂点击提交订单按钮导致重复下单；二是多个用户同时购买同一件库存只剩1件的商品。我的处理方案是：在orders表里用唯一订单号（order_no）做防重，在扣库存的SQL里加上WHERE stock >= quantity的条件，受影响行数为0说明库存不足，直接抛异常回滚。整个下单方法打上@Transactional，任何一个环节出错，订单和库存数据都能恢复到操作前状态。3. 后端SpringBoot核心实现解析3.1 工程目录结构与统一响应模型后端工程我习惯按“Controller-Service-Mapper”三层划分，包名按模块组织，和普通公司项目保持一致。目录结构大致是这样：com.yiyi ├── common // 全局异常、统一结果、常量、工具类 ├── controller // 接口层：ProductController、OrderController等 ├── service // 业务层：接口+实现类 ├── mapper // MyBatis的Mapper接口 ├── entity // 数据库实体类（与表字段一一对应） ├── dto // 前端传输对象（接收参数和返回视图对象） ├── config // 配置类：跨域、拦截器、MyBatis-Plus相关配置统一响应对象是前后端分离项目的基石。如果没有它，每个接口返回的字段结构就会五花八门，前端完全没法写统一的处理逻辑。我在common包里定义了一个Result类：public class Result<T> { private Integer code; // 200成功 500失败 401未登录 private String message; private T data; public static <T> Result<T> success(T data) { ... } public static <T> Result<T> error(String message) { ... } }配合全局异常处理器@RestControllerAdvice，service层一旦抛出BizException（自定义业务异常），前端能收到结构一致的错误响应。我一直认为这部分代码虽然看起来“不起眼”，但它决定了前后端联调时是事半功倍还是事倍功半。3.2 商品查询：分页+多条件筛选的实现商品列表页是用户进入系统后最先接触的页面，对查询接口的要求是：支持分类筛选、商品名模糊搜索、价格排序、分页加载。我直接在Mapper层写动态SQL，用<where>标签和<if>标签来拼条件：<select id="selectProductPage" resultType="com.yiyi.entity.Product"> SELECT * FROM product <where> status = 1 <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> AND name LIKE CONCAT('%', #{keyword}, '%') </if> </where> <choose> <when test="sort == 'price_asc'">ORDER BY price ASC</when> <when test="sort == 'price_desc'">ORDER BY price DESC</when> <otherwise>ORDER BY id DESC</otherwise> </choose> </xml>分页我用的是MyBatis的分页插件PageHelper，调用方式极其简单：在查询前执行PageHelper.startPage(pageNum, pageSize)，紧接着的第一次SQL查询就会自动拼接LIMIT，同时会生成一个PageInfo对象，里面包含total、pages、list等分页数据。这里有个经验之谈：PageHelper的startPage只对紧跟着的第一个查询生效，所以如果查询前要先做别的操作（比如先查分类再查商品），就会导致分页失效甚至报错。我在页面加载时要同时返回分类列表和商品列表，就拆成了两个独立接口，前端并行请求，完美避开这个坑。3.3 购物车下单与库存扣减的核心流程下单接口是“衣依”系统里业务逻辑最集中的地方，核心Service方法我来拆解一下整体流程：@Transactional public OrderVO submitOrder(OrderSubmitDTO dto) { // 1. 校验用户登录态并获取收货地址 Address address = addressMapper.selectByPrimaryKey(dto.getAddressId()); if (address == null) throw new BizException("收货地址不存在"); // 2. 根据购物车ID列表查询所有勾选商品 List<CartItem> cartItems = cartMapper.selectCheckedItems(dto.getMemberId()); // 3. 逐一校验商品状态和库存 for (CartItem item : cartItems) { Product product = productMapper.selectByPrimaryKey(item.getProductId()); if (product.getStatus() != 1) throw new BizException("商品已下架"); if (product.getStock() < item.getQuantity()) throw new BizException("商品库存不足"); } // 4. 生成唯一订单号并创建订单主记录 String orderNo = "YY" + System.currentTimeMillis() + RandomUtil.randomNumbers(4); // 计算总金额，写入订单表（含收货信息快照） // 5. 生成订单明细快照，同时扣减库存 for (CartItem item : cartItems) { Product product = productMapper.selectByPrimaryKey(item.getProductId()); orderItemMapper.insert(...); // 存入商品名、图片、价格快照 int rows = productMapper.reduceStock(item.getProductId(), item.getQuantity()); if (rows == 0) throw new BizException("库存扣减失败"); } // 6. 清空已下单的购物车 cartMapper.deleteByIds(...); return buildOrderVO(order); }整个方法只有@Transactional一个注解，但数据库事务却做了四件事：插订单、插明细、扣库存、清购物车。一旦中间任何一步失败，全部回滚，不会出现“订单创建了但库存没减”或者“库存减了但购物车没清”的数据不一致问题。这里再补充一个细节：模拟支付接口做的事其实特别简单，就是校验订单属于当前用户且状态为待支付，然后UPDATE orders SET status = 1, pay_time = NOW() WHERE order_no = ? AND status = 0，受影响行数为1即支付成功。用条件更新可以再次防止并发下的状态错误。3.4 登录鉴权：JWT还是Session？“衣依”作为前后端分离项目，登录态管理最合适的方案是JWT。服务器的处理逻辑是：用户登录成功后，用userId和username生成一个带过期时间的token，返回给前端；前端每次请求在Authorization头里带上token；后端通过拦截器（HandlerInterceptor）统一解析，未登录请求直接返回401。public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || !JwtUtil.verify(token)) { // 返回401并写出Result对象 return false; } // 从token中取出userId放入request request.setAttribute("userId", JwtUtil.getUserId(token)); return true; } }注册登录的密码存储我用了MD5加盐处理，虽然现在更推荐BCrypt，但对于学习项目用MD5+固定盐也够演示。拦截器放行规则要注意：商品查询、分类查询、首页轮播图这些公开接口必须放行，涉及个人中心、购物车、下单的接口必须拦截。另外要处理一个容易忽略的问题：用户下单、查看订单时，后端绝不能直接信任前端传来的userId，而必须从token解析出来的用户身份为准，否则就会出现“水平越权”漏洞。我在“衣依”里所有订单查询方法都强制带上前端传的memberId和token里的userId做二次比对。4. 前端Vue3实现与联调关键点4.1 前端工程结构与状态管理前端使用Vite作为构建工具，目录和组件划分如下：src ├── api // 接口请求封装（按模块拆分） ├── router // 路由配置与守卫 ├── store // 状态管理（用户信息、购物车数量） ├── views // 页面组件 │ ├── Home.vue // 首页 │ ├── ProductList.vue // 商品列表 │ ├── ProductDetail.vue │ ├── Cart.vue // 购物车 │ ├── OrderConfirm.vue │ ├── OrderList.vue │ ├── Login.vue │ └── UserCenter.vue └── components // 公共组件（Header、Footer、商品卡片等）状态管理选择上我用了Pinia，比Vuex更简洁且对TypeScript更友好。用户登录成功后会同时把token和用户基本信息存进Pinia，并用localStorage做持久化，刷新页面后还能保持登录状态。另外购物车角标的数量我单独放在一个useCartStore里，每次增删购物车后都会重新拉取数量，保证Header展示的角标和实际数据一致。路由守卫是前端鉴权的重要一环：在router.beforeEach里检查要访问的页面是否需要登录（通过路由meta字段标记），如果未登录则跳转到登录页，登录成功后通过redirect参数回到原页面。这个体验细节很加分。4.2 首页、商品列表与购物车交互首页一般由轮播图、分类导航、热门商品几个区域组成。我把首页看作一个“组合页面”，通过几个子组件拼装，数据统一在Home.vue里通过onMounted并发请求三个接口加载。这样页面加载最快，每个接口独立loading，一个接口失败不会影响其他区域展示。商品列表页是重点，用户通过顶部导航或首页分类进入。我用了watch监听路由参数categoryId和查询参数keyword的变化，参数一变就重新请求列表数据。分页用的是滚动到底部自动加载更多，而不是传统页码翻页，更符合商城类App的使用习惯。这个用onMounted监听window.scroll事件实现，注意在组件卸载时移除事件监听，避免内存泄漏。购物车页面有一个细节要处理好：勾选商品、修改数量、计算总价都是纯前端状态操作，只有点击“去结算”时才把购物车ID列表提交到后端生成订单。前端实时计算总价用computed依赖购物车项里的checked和quantity，不需要每次点击都请求后端接口，体验非常流畅。4.3 axios封装与开发环境跨域处理前后端分离开发时，前端地址是localhost:5173，后端是localhost:8080，浏览器跨域问题不可避免。我在Vite的配置文件里加了代理：// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, } } } })这样前端请求/api/product/list实际会代理到http://localhost:8080/api/product/list，浏览器不再直接跨域，而后端的跨域配置只是兜底方案。我习惯统一在axios实例里设置baseURL: '/api'，所有接口以/api开头，这样后面如果部署到nginx，也只需要调整nginx的路径转发规则。axios的拦截器做了两件事：请求拦截器把Pinia里的token加到请求头Authorization；响应拦截器只处理Result对象，如果code不为200就弹出提示信息，同时单独处理401（token过期）跳转到登录页。这样业务代码里就不需要反复写错误处理逻辑了。5. 本地部署与运行实操5.1 环境准备与数据库初始化要把“衣依”系统在本地跑起来，需要准备以下基础环境：JDK 1.8或11、Maven 3.6以上、MySQL 5.7或8.0、Node.js 16以上（推荐18）。IDE我个人喜欢用IntelliJ IDEA，前端用VS Code。拿到源码后，第一步是执行项目根目录下的yiyi.sql脚本。里面有建库建表和初始数据，建议直接用命令行或Navicat整体执行。执行完确认数据库yiyi下能看到十几张表和若干条测试数据。项目里自带的测试账号有两个——前台用户账号密码通常是admin/123456，管理端是manager/123456，跑起来后可以直接登录体验。第二步是修改后端application.yml中的数据库连接信息：server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/yiyi?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver这里要特别注意serverTimezone=Asia/Shanghai这个参数。如果省略，国内服务器用默认时区可能会导致时间差8小时甚至启动报错。5.2 后端启动与接口自测后端启动非常简单，在项目根目录执行：mvn spring-boot:run看到“Started Application in xx seconds”日志就代表启动成功。如果Maven下载依赖时速度太慢，可以在~/.m2/settings.xml里配置国内镜像源。接口自测我强烈推荐用Apifox或者直接用Postman。先调一次登录接口获取token，然后测试商品查询、加入购物车、提交订单的接口。注意测试下单前先在数据库里给测试用户添加一条收货地址，不然下单会提示地址不存在。对于“衣依”这种自带Swagger配置的项目，也可以直接访问http://localhost:8080/swagger-ui.html进行可视化接口调试，比纯手写请求体更直观。5.3 前端启动与全流程验证前端在项目前端的目录下执行：npm install npm run dev启动成功后终端会打印Vite的访问地址，一般是http://localhost:5173。首次启动要是遇到npm install报错，优先检查Node版本，Vite3要求Node14.18以上，Vite5要求Node18以上。打开页面后完整走一遍核心流程：注册一个全新账号 -> 首页浏览 -> 进入商品详情 -> 加入购物车 -> 结算下单 -> 模拟支付 -> 在个人中心查看订单。同时用管理端账号登录后台，把订单标记发货，再回到用户端确认收货。这套流程全部走通，就说明前后端所有核心接口都正常了。6. 常见问题排查与实战避坑6.1 启动与运行常见问题速查表问题现象可能原因排查与解决方案后端启动报数据库连接失败数据库没启动 / 账号密码错 / URL里的库名不对先用Navicat测试连接，检查application.yml的三项配置前端启动成功但页面白屏接口全部404或500打开浏览器F12看Network的具体状态码，排查代理配置和后端是否启动登录接口返回401token生成或拦截器逻辑问题检查拦截器放行了登录接口，检查JWT密钥是否一致MyBatis查询出null字段表字段下划线转驼峰未配置在application.yml开启map-underscore-to-camel-case: true时间字段显示为时间戳Jackson序列化配置缺失在application.yml配置时间格式化或使用@JsonFormat注解提交订单报库存不足并发扣减/测试数据库存为0检查reduceStock的SQL是否带stock >= quantity条件前端刷新页面404路由模式为history开发环境用Vite的historyApiFallback，生产环境由nginx配置try_files处理6.2 我踩过的几个坑，给各位提个醒第一个坑是MyBatis的驼峰映射。数据库字段是create_time，实体类属性是createTime，如果不开启驼峰映射，这个字段永远是null。新手很容易排查半天才发现是配置项漏了。我的做法是在application.yml里统一加上：mybatis: configuration: map-underscore-to-camel-case: true第二坑是查询列表时把大字段全查出来了。商品表里有个detail字段存的是很长的HTML详情，如果列表接口SELECT *，不仅传输慢还拖垮渲染。我的做法是列表接口用单独的SQL只查id, name, price, main_image, subtitle，详情接口才查完整字段。这算是很基础但非常实用的性能优化。第三个坑是图片上传后的访问路径。项目里的商品图片是上传到本地磁盘某个目录的，如果上传成功了但页面加载不出图片，八成是上传路径和静态资源映射目录对不上。后端的资源映射配置要指向实际文件目录，否则前端访问不到。最简单的做法是上传接口返回完整的可访问URL，前端直接展示，避免二次拼接出错。第四个坑是前端路由的history模式部署问题。开发环境下一切正常，但打包部署到服务器后，刷新页面除了首页，其他路径全部404。原因是路由切换是前端路由，但刷新时浏览器会以当前路径请求服务器，服务器没有对应的后端路由，自然报404。解决办法是在nginx上配置try_files $uri $uri/ /index.html;，把不存在的路径都fallback到前端入口。这个在项目部署文档里一定要写清楚。第五个坑是删除购物车数据时用foreach逐条删除，性能不好且事务太长。我后来改成了按用户ID和商品ID集合批量删除，一条SQL搞定。类似的批量操作还有订单列表查询，不要用循环查数据库，要学会用IN查询一次取出所有关联数据。做这类项目我最大的体会是：技术本身没有太多高深的东西，真正的难点在于把每个模块间的数据流转理清楚，把边界条件想透。“衣依”这个系统单看代码量不算大，但商品、购物车、订单、库存这些环节串起来后，就是一个小而完整的电商闭环。如果你跟我一样是冲着练手来的，建议拿到源码后先别看实现，自己先画一遍业务流程图和数据表关系图，再对照代码看差异，这样收获会大得多。最后再分享一个扩展方向：这个项目最值得升级的地方是商品SKU管理和优惠券模块。商品表加一个sku表，把颜色、尺码、库存下沉到规格层级；优惠券则牵涉到领取、核销和订单金额计算，能把业务复杂度提升一个档次。把这两块啃下来，你对电商系统的理解会比现在深很多。