大半年前我接手了一个“游泳用品专卖店系统”的活儿，需求不算复杂，但五脏俱全——有商品展示、购物车、下单流程，还要有后台管理、库存扣减、订单状态流转这些基本功。技术栈很明确：Spring Boot做后端。我一开始以为这也就是个普通的CRUD项目，真正动手才发现，泳具类目本身的差异化需求（比如尺码、近视度数、款式分类）加上库存和订单的联动，才是最容易翻车的地方。这篇文章我打算把整个设计和实现过程完整拆开来讲，包括我踩过的坑和最后采用的方案，给同样在做商城类Spring Boot项目的朋友一个参考。
1. 需求边界定下来之后，我才开始动数据库
这个项目的核心业务就是“游泳用品专卖店”，听起来很小，但实际上商品种类并不算少：泳衣泳裤按尺码和性别分、泳镜按近视度数和成人/儿童分、泳帽按材质和松紧程度分、脚蹼和浮板又按规格型号分。如果一开始就把表结构设计成“一张商品表，一堆字段堆上去”，后面做筛选、做库存，都会非常痛苦。
我拿到需求后在纸上先把角色画了出来：C端用户（注册会员、浏览商品、管理购物车、下单、查看订单）、后台管理员（商品管理、类目管理、订单处理、会员信息查看）。明确好这两个角色之后，功能边界就很清楚了，系统不需要做分销、不需要做评论审核、不需要做优惠券引擎，那在数据库设计阶段就可以砍掉这些表。
1.1 商品类目与商品详情的拆分思路
游泳用品这块，我最后是这么拆的：
- 分类表：一级分类（泳装、泳镜、泳帽、配件），二级分类（比如泳装下面再分男士泳裤、女士泳衣、儿童泳衣）。
- 商品表：公共属性，比如名称、主图、简介、所属二级分类、上下架状态。
- 商品参数表：专门存差异化的规格参数，比如泳镜有“度数可选”，泳帽有“头围范围”。这里用灵活键值对，而不是每个参数建一个字段。
- 商品SKU表：真正决定价格和库存的层级，一条SKU对应一个具体的规格组合（例如“男士泳裤-黑色-2XL”）。
这样拆的好处非常直接：商品表保持干净，分类下新增品类时不需要改表结构。如果做泳镜这种有度数属性的商品，也只需要在参数表里加一条，而不是动数据库字段。
1.2 订单与库存表的设计防线
订单相关我设计了四张核心表：订单主表、订单明细表、库存流水表、购物车表。这里特别想说一下库存流水表，很多小项目根本没有这张表，结果订单状态一乱，库存对不上账，查都没法查。
我在设计订单和库存的时候，定了一条硬性规则：任何库存变化都必须落一条流水记录，包括下单占用、支付确认扣减、取消释放、后台手动调整。这样一旦出现“系统显示有货但就是发不了货”的诡异问题，可以直接查流水定位，而不是靠猜。
购物车表我关联了用户ID和SKU ID，数量字段做了默认值1和上限校验。这个表看起来简单，实际上最容易被忽略的是“加入购物车时是否需要锁定价格”，我的选择是不锁定，购物车只存SKU引用，真正下单时再读一遍当前SKU价格并写入订单明细表快照。这个考量是基于电商常识：购物车阶段价格变化是常态，订单阶段才必须固化价格。
2. 核心模块的后端实现：不只做CRUD，要想清楚状态流转
Spring Boot给这类MVC项目提供了一套很成熟的架子——Controller层接收请求、Service层写业务、Mapper层操作数据库。但真正写起来，业务复杂不在增删改查，而在流程状态的管理。
2.1 注册登录模块与密码处理
用户注册登录我用的是Spring Security结合JWT。很多人一听到Spring Security就觉得重，实际上对于单体项目来说，配一次就够了，不会多出多少复杂度。
密码存储方面，现在谁还明文存密码那就是给黑客送人头。我用BCrypt加密，注册的时候加密入库，登录的时候匹配。Spring Security的BCryptPasswordEncoder直接就能用，不需要自己实现加密算法。
注册的时候我还加了两个校验：一是手机号格式合法性，二是邮箱格式合法性，两者至少填一个。这个设计是因为游泳用品的消费者里有一部分是企业团购或俱乐部批量采购，他们不一定愿意绑定手机号，邮箱渠道有时候也是刚需。
JWT这块，我用一个拦截器统一解析请求头里的Token，把用户ID注入到上下文。登录接口和公开接口做一个白名单配置，其他接口一律要求登录。这个拦截器比在每个Controller里加判断要省事得多，代码也干净。
2.2 商品列表与筛选接口的坑
商品列表接口是我觉得最像“实际项目”的地方，因为它不只是一个简单的SELECT * WHERE status = 1。用户在C端看到的应该是已上架商品，而且支持按二级分类筛选，后台管理员看到的则是全部商品，包括已下架和库存为零的。
关键点在于：C端和B端的商品查询最好分开写两个接口，而不是一个接口加个参数硬切换。原因很简单，两个场景的字段权限不一样，C端不需要看到成本价、库存预警值这些敏感字段；如果硬塞进同一个VO里，返回一坨null字段非常膈应。
列表接口还需要支持分页。我用的是MyBatis-Plus的Page对象，传入pageNum和pageSize，返回总条数和当前页数据。筛选条件我用了一个QueryDTO来接收，里面包含分类ID、关键字、价格区间、排序字段。排序我固定做白名单，只允许price_asc、price_desc、sales_desc、create_time_desc这几种，不然容易被SQL注入或者搞出不存在的排序字段。
2.3 购物车与下单业务串联
购物车的接口比较简单，增删改查，但有一件事必须做：在加入购物车时检查SKU是否存在、是否上架、库存是否大于0。这不仅仅是体验问题，更是防止脏数据把订单流程带崩。
下单是整个项目中业务逻辑最密集的操作，我用一个事务方法包起来，步骤是：
- 读取购物车中勾选的条目；
- 校验每一个SKU的状态和库存；
- 按当前价格生成订单主表和订单明细表记录；
- 占用库存——这里我把SKU表的库存字段扣减掉，同时插入一条“占用”类型的库存流水；
- 清空已下单的购物车条目。
这一步我特意留意了事务边界。用户在创建订单之后、支付确认之前，库存其实是被预占的。如果什么都不做，库存会一直挂着，所以需要一个超时释放机制。我这个系统用了最简单的方案：数据库定时任务每隔10分钟扫描一次超过30分钟未支付的订单，把SKU库存加回去，插入“超时释放”流水，并把订单状态改为已关闭。
2.4 订单状态的几个关键流转
订单状态我设计成五个：待支付、待发货、已发货、已完成、已取消。流转规则我用状态机的方式固化下来：
- 待支付 -> 支付成功 -> 待发货；
- 待支付 -> 30分钟超时 -> 已取消；
- 待发货 -> 管理员发货 -> 已发货；
- 已发货 -> 用户确认收货 -> 已完成；
- 待支付 -> 用户主动取消 -> 已取消。
为什么强调状态机？因为如果直接在前端随便改状态，后台一塌糊涂。我这边的做法是在Service层写一个changeOrderStatus方法，里面用一个Map或者条件判断来校验当前状态和目标状态是否合法，非法流转直接抛业务异常。
3. 表结构设计的关键字段与取舍说明
写代码之前，建表的细节值得多说一嘴，因为很多新手在项目验收的时候被数据库设计卡住。下面是我实际建表的核心字段清单和理由。
3.1 数据库字段规范
我统一用create_time和update_time作为公共时间字段，同时所有关键表都加了deleted逻辑删除字段，默认0。这里有个小建议：逻辑删除是做安全备份的手段，但不能用它代替唯一索引。比如商品SKU的sku_code唯一索引，是硬性约束，谁也不能重复，和逻辑删除无关。
3.2 游泳用品特有属性的存储方案
我刚才提到用参数的键值对存泳镜度数、泳帽头围这些属性。具体实现是这样：
我有一张product_param表，结构是id, product_id, param_name, param_value。比如某款泳镜产品ID是1001，那它下面会有三行记录：度数=-2.00、度数=-2.50、度数=-3.00等等。页面渲染的时候按照param_name分组展示，非常灵活。
对应的SKU表结构是：id, product_id, sku_name, sku_code, price, stock, status, spec_json。其中spec_json存具体规格的ID组合，比如泳镜产品下某条SKU的spec_json存“近视-2.00, 黑色, 标准款”。这个概念直接用JSON字符串存储，省去规范化的复杂关联，查询时解析效率也够用。
3.3 表关系带来的启发
整体表关系并不复杂：分类表1对多商品表、商品表1对多SKU表、商品表1对多参数表、订单主表1对多订单明细表、用户表1对多订单表、SKU表1对多库存流水表。梳理下来，最忌讳的是在业务表里无序增加冗余字段。比如订单明细表必须冗余商品名、商品主图、SKU规格文本这些下单时快照数据，但绝不能在订单明细表里去关联商品表实时取商品名。
4. Controller层与API响应格式的约定
写接口多了之后，我养成了一套固定习惯：所有接口统一返回一个Result<T>对象，包含code、message、data三个字段。这样前端解析逻辑可以统一，不管成功还是失败，HTTP状态码一律200，业务态用code区分。
我这里简要定义一下：
public class Result<T> { private Integer code; // 200成功，400参数错误，401未登录，500系统异常 private String message; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.code = 200; r.message = "success"; r.data = data; return r; } public static <T> Result<T> fail(Integer code, String message) { Result<T> r = new Result<>(); r.code = code; r.message = message; return r; } }全局异常处理用@RestControllerAdvice包一层，业务异常类BizException向下继承RuntimeException。这样代码里任何地方直接throw new BizException("库存不足")，最终响应都是{"code":400,"message":"库存不足"}，非常干净。
4.1 API路径设计与命名习惯
我按照REST风格拆了几组接口路径：
- 商品：
GET /api/product/page，GET /api/product/{id}，POST /api/admin/product，PUT /api/admin/product/{id}； - 购物车：
GET /api/cart/list，POST /api/cart/add，POST /api/cart/remove，POST /api/cart/update； - 订单：
POST /api/order/create，GET /api/order/list，GET /api/order/{id}，POST /api/order/pay/{id}； - 后台管理：
POST /api/admin/order/ship，PUT /api/admin/sku/stock。
实际上手时你会发现REST风格并不是死的。比如购物车的移除，用DELETE /api/cart/{id}更符合语义，但前端同学如果用习惯了POST /api/cart/remove也问题不大。关键是整个团队约定统一，别一个项目里两种风格混着来。
4.2 参数校验与防刷
每个Controller的请求参数，我都用javax.validation的注解校验：@NotNull、@Min、@Max、@Size，在DTO字段上直接标。加一个@Valid就搞定了。
防刷这件事在这个项目里不太重，毕竟不是高并发秒杀系统。但为了防止有人写脚本扫接口，我在几个写操作接口上加了一个简单的IP频率限制，内存里存一个ConcurrentHashMap<String, LocalDateTime>即可。这种方式只能对付最低级的脚本，真要高强度防护还得上Redis加分布式限流，这里就不展开了。
5. 从单体应用角度总结部署上线的几个注意事项
Spring Boot项目最终是要打成JAR包部署的。这里有一些我试过的部署配置和遇到的问题，值得单独说一段。
5.1 多环境配置
我建了application-dev.yml、application-prod.yml和主配置文件application.yml。主配置里只放通用内容，环境差异全部按不同文件区分。启动命令用java -jar app.jar --spring.profiles.active=prod来切环境。
生产环境数据库连接串、账号密码绝不写死在配置文件里，用环境变量注入。比如在启动脚本里先export DB_HOST=xxx，配置里写jdbc:mysql://${DB_HOST}:3306/swim_shop。这样即使代码泄露，数据库也不是裸奔状态。
5.2 静态资源和文件上传
商品图片上传我用了本地磁盘路径存储，然后Nginx做静态资源映射，数据库里只存图片的相对路径。这个方案适合中小项目。如果你图省事把图片直接存数据库的BLOB字段，查询列表时性能会很差，而且备份数据库体积会爆炸。
图片上传接口还要做大小和类型校验，图片最大5MB、只允许jpg/png/webp，不然用户传个恶意脚本伪装成图片文件，虽然不一定直接造成危害，但总归是个风险点。
5.3 日志的重要性
系统运行中日志我认为是必须写好的。我在生产环境配置了Logback，按天生成日志文件，保留30天。关键业务节点（下单、支付、发货、取消）必须打印业务日志，包含订单号和操作人。
订单一出问题，看日志是最快的排查路径。如果日志里看不出完整链路，真出了问题就只靠猜了，这对运维来说是不可接受的。
6. 复盘：这个项目里我学到的几件“书上不写的事”
项目收尾之后，我回头看了看代码和设计记录，有一件事体会很深：Spring Boot本身只是一套快速脚手架，真正决定项目成败的是业务建模和边界划分。
具体到游泳用品专卖店这个场景，如果一开始没想清楚SKU和商品参数的关系，后面做泳镜度数筛选、泳帽头围筛选的时候就会各种别扭；如果没设计好库存流水表，上线第一个月就会遇到“账实不符”的扯皮问题；如果订单状态机不固定，前后端各写各的，最后倒霉的还是用户。
6.1 关于事务和并发的一个实用补充
库存扣减我用了数据库行锁来避免超卖，核心SQL类似于：
UPDATE product_sku SET stock = stock - #{count} WHERE id = #{skuId} AND stock >= #{count}这条语句靠stock >= #{count}条件保证不会扣成负数，加行锁保证并发安全。如果更新影响行数为0，直接抛“库存不足”异常。这种方案在高并发下依然有性能瓶颈，但对专卖店这种量级完全够用。
6.2 给后来者的几个建议
第一，先画状态流转图再写代码，哪怕用纸画都行。第二，所有时间字段尽量用数据库的CURRENT_TIMESTAMP维护，少在代码里手工new Date()。第三，接口返回数据用Map或者VO封装，不要直接返回Entity，免得把敏感字段泄露出去。
我在做这个项目的时候踩过一个印象深刻的坑：刚开始偷懒，直接返回了User实体，结果序列化后把密码的Hash也带出去了，虽然前端没显示，但抓包能看到就是个安全隐患。后来统一加了@JsonIgnore敏感字段，又改用VO层返回，才彻底解决这个问题。
这套系统最后顺利上线，跑了两个多月没有出现严重线上事故。如果让我概括这个项目的关键词，大概就是“稳”和“清晰”。Spring Boot提供的生态确实让单体应用的开发效率提升了一大截，但作为开发者，脑子里始终要有一根弦：框架只是工具，业务逻辑和数据结构设计才是真正需要反复推敲的地方。
最后说一个小细节：这个项目的启动类继承Spring Boot标配的main方法，用IDEA的插件可以直接打包成Docker镜像，配合一键部署脚本，整个发布过程也就两三分钟。很多人忽略的其实是这一层——从能跑的代码到能稳定交付的代码，中间还隔着不少运维功夫。
希望这篇实战复盘能帮到你。不管是毕设还是小公司的实际需求，游泳用品专卖店这个系统类型都是练手的好题材，你把它做完做扎实，电商类项目的核心思路基本就摸透了。
