最近帮几个毕业设计的同学远程调试基于SpringBoot的水族馆商品销售与经营管理系统，发现大家拿到一套完整源码之后，最大的问题不是电脑上跑不起来，而是“不知道从哪讲起”。但如果你把这套系统的功能、数据库、后端流程、部署细节都吃透，你会发现，在毕设答辩和项目复盘里讲它，比讲十个玩具级Demo都更站得住脚。因为它天然就是一个完整的“前台商城+后台管理”双端应用，涉及到商品浏览、购物车、下单、支付模拟、库存管理、会员列表、公告管理、经营报表。对想入门Spring Boot的同学来说，这是一份很好的参考项目——结构不复杂，但把电商后台的核心链路都走了一遍。
这篇把我拆解这套系统时的一些关键思路、数据库设计、核心代码逻辑，以及远程调试时容易踩的坑，一次性说清楚。不是照着文档念，而是讲“为什么这里要这么写”。
1. 整体设计与思路拆解
1.1 为什么把系统拆成“用户商城+管理后台”
市面上很多毕设管理系统只有单一管理后台，几张表、几个页面，展示效果有限。但水族馆商品销售题目的关键在于“销售”两个字，如果只做后台管理，就没有办法向评审老师展示完整的交易闭环。所以这类系统的合理拆法，是把系统分成两个终端：
- 用户端：注册登录、商品分类浏览、商品详情、购物车、确认下单、模拟支付、订单查询、个人资料。
- 管理端：商品管理、类目管理、库存预警、订单处理、会员管理、公告发布、经营数据统计。
这样拆完以后，逻辑就顺多了。用户端面对的是顾客，主要目标是“能买、能查、能追踪订单状态”；管理端面对的是运营和店长，主要目标是“能管、能统计、能及时补货”。两套页面共用同一个关系型数据库，但业务上彼此隔离，用户进不了后台地址，管理员也只需要管运营数据。
从这个角度看，这套系统的定位不只是“增删改查”，而是一个可以讲出业务故事的双端电商原型。把“顾客下单”和“管理员发货”这两个角色串起来，就能在演示时形成完整叙事。
1.2 为什么选SpringBoot，而不是SSM或现成脚手架
很多同学纠结过一个问题：毕设用SSM还是SpringBoot？说实话，如果从学习原理的角度，SSM值得动手搭一次，但从完成项目和答辩的角度，SpringBoot是更理性的选择。两者的主要差异我列个表：
| 选项 | 上手成本 | 配置量 | 适合场景 | 主要注意点 |
|---|---|---|---|---|
| SSM | 偏高 | 较多 | 教学演示、框架原理学习 | 需要手动维护XML配置，依赖版本容易冲突 |
| SpringBoot | 低 | 少 | 快速开发、毕设项目 | 需要理解自动配置和约定规则 |
| 业务脚手架类框架 | 中等偏高 | 低 | 快速后台管理 | 代码量大，需要先理解框架自身的组织方式 |
SpringBoot的优势不仅在于内嵌Tomcat、不用单独部署，还在于它把很多规则变成了约定。比如自动装配数据源、自动识别Controller、内嵌文件上传限制等。对分秒必争的毕业季来说，能少花两天配置就少花两天。
有人建议直接套用现成的脚手架，我反而觉得没必要。很多脚手架自带复杂的用户权限体系、代码生成器、额外组件，表面看省事，实际改造起来成本很高。答辩时容易被追问一些原理层面的问题，到时如果说不清楚框架内部的结构，反而扣分。自己写一套结构清晰的SpringBoot项目，业务代码在本地，逻辑也更容易讲明白。
2. 数据库设计与水族馆业务字段建模
2.1 核心表结构与字段设计意图
水族馆商品销售系统，数据库表一般围绕用户、商品、订单三条主线展开。我按常见设计拆一份表清单：
| 表名 | 主要职责 | 关键字段 |
|---|---|---|
| user | 用户和会员信息 | user_id、username、password、phone、level_id |
| category | 商品分类 | category_id、name、parent_id |
| product | 商品主体 | product_id、category_id、name、main_image、detail、price、stock、status |
| cart | 购物车临时数据 | cart_id、user_id、product_id、quantity |
| order_info | 订单主表 | order_id、order_no、user_id、total_amount、status、receiver_info |
| order_item | 订单明细表 | item_id、order_id、product_id、product_name、price、quantity |
| member_level | 会员等级 | level_id、level_name、discount、threshold |
| notice | 公告 | notice_id、title、content、create_time |
除通用字段外，水族馆类目特有的业务字段也值得注意。比如观赏鱼商品需要记录适宜水温、水质类型、成体体长等信息；设备类商品要记录功率、适用缸体大小。这些字段如果不在表设计阶段预留，后面就只能硬塞在“商品参数”文本字段里，查询和展示会很受限。比较好的做法是商品表保留通用属性，把特定类目参数做成单独的扩展表，或者用JSON格式字段存放，方便解析。
订单表拆主表加明细表，可能有些初学者不理解。举个例子：顾客一次买一条罗汉鱼、一个加热棒、一袋饲料，是一次下单，但这三样商品会被合并在一个订单主表里。如果不拆明细，订单表就只能用逗号把商品名拼在一起，后续做发货、统计、退款都非常痛苦。订单主表存一次交易的整体信息，订单明细表存这次交易里的每一行商品数据，两者是一对多的关系，这是电商系统里最基本的建模思路。
2.2 订单状态机与防超卖设计
订单状态是这套系统里最值得展开的部分。常见状态可以这样定义：
| 状态值 | 含义 | 触发动作 |
|---|---|---|
| 0 | 待付款 | 用户提交订单 |
| 1 | 已付款/待发货 | 用户模拟支付成功 |
| 2 | 已发货 | 管理员后台点击发货 |
| 3 | 已完成 | 订单到达收货确认 |
| 4 | 已取消 | 未付款主动取消/超时取消 |
在实现时，建议把这些状态值定义成常量或枚举类，避免在代码里到处写魔法数字。比如OrderStatusEnum里面放一个getDesc()方法，前端页面上直接显示文字描述，后端用数字做判断，职责清晰，也方便后续扩展。
库存扣减要注意防超卖。很多初学者写扣库存是stock = stock - 1，这样在高并发下容易把库存减成负数。虽然毕设系统并发量不高，但如果在答辩中讲出“我用update语句配合库存条件来避免超卖”，就是实打实的加分点。核心SQL可以这样写：
update product set stock = stock - #{quantity} where product_id = #{productId} and stock >= #{quantity}这条语句通过stock >= #{quantity}条件，保证只有当库存足够时才执行update，避免扣成负数。同时数据库本身的行锁机制，也能在并发场景下保证不会相互覆盖。
3. 后端核心流程实现与关键代码
3.1 购物车：存数据库还是存Session
购物车的实现有两种路线：Session存储和数据库表存储。Session方案胜在实现快，所有数据都在内存里，重启就丢，而且不能跨设备同步；数据库方案多写几个Mapper，但便于查询用户加购记录，也能在订单生成后直接从购物车表读取数据。
对于水族馆商品销售系统，我更建议用数据库表实现购物车。原因很简单：后续如果要加“购物车商品活动价”“用户偏好分析”等功能，数据落库以后才能继续深入。购物车表的核心操作是两种：加购时检查同一用户是否已经加过同一商品，如果存在就累加数量；下单成功后按用户ID清空对应商品记录。
public void addCart(Long userId, Long productId, Integer quantity) { Cart cart = cartMapper.selectByUserIdAndProductId(userId, productId); if (cart == null) { cart = new Cart(); cart.setUserId(userId); cart.setProductId(productId); cart.setQuantity(quantity); cartMapper.insert(cart); } else { cart.setQuantity(cart.getQuantity() + quantity); cartMapper.updateById(cart); } }这个小逻辑看起来简单，但里面藏着“幂等”的思想——重复提交不会产生重复记录，而是更新已有记录。答辩时如果被问到接口重复提交问题，可以用这段逻辑来引出话题。
3.2 下单事务：库存、订单、购物车如何保持同步
下单是整套系统中最应该讲清楚的核心流程。它涉及到三个动作：扣减库存、生成订单主表、生成订单明细、清空购物车。这四个动作必须要么全部成功，要么全部失败，否则就会出现库存扣了但订单没生成，或者订单生成了但购物车没清空的情况。
SpringBoot解决这类问题最简单的方式就是@Transactional。这个注解表示方法内发生的数据库操作在同一个事务里，遇到运行时异常就整体回滚。
@Transactional public Long createOrder(OrderCreateParam param) { // 1. 校验商品是否存在且上架 // 2. 扣减库存，使用条件update防超卖 // 3. 生成订单主表 // 4. 生成订单明细 // 5. 删除购物车中已下单的商品 // 6. 返回订单号 }这里有一个很多人踩过的坑：@Transactional默认只对运行时异常和错误回滚，遇到Checked Exception就不会回滚。比如库存扣减成功后，插入订单明细时抛出一个IOException，事务可能不会正常回滚。稳妥做法是在Service方法里手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()，或者把异常统一包装成自定义的RuntimeException抛出。
订单号生成也值得说一说。建议用时间戳加随机数的组合，比如yyyyMMddHHmmss加四位随机数，或者直接用UUID去掉横线后截取。不要用数据库自增ID直接当订单号暴露给用户，避免别人通过订单号推测店铺的订单量。
3.3 经营统计：SQL聚合比内存计算更适合
后台的“经营报表”模块，是这套系统区别于普通CRUD项目的核心亮点。常见的统计点有今日销售额、今日订单数、商品销量Top10、近7日销售趋势、会员消费占比。看过一些同学自己写的统计代码，是直接把所有订单全部查出来，再用Java的for循环算总额。这在数据量小的时候能跑，但数据一旦过万，内存消耗和接口响应时间就不好看了。
更合理的做法是让数据库先聚合，再返回少量结果。比如统计近7天销售额：
select date(create_time) as day, sum(total_amount) as total from order_info where status in (1, 2, 3) and create_time >= date_sub(curdate(), interval 6 day) group by date(create_time) order by day;在Service层把这条SQL的结果List直接转成前端需要的结构，返回{ days: [...], totals: [...] }。这样后端只回传7个日期和7个金额，前端图表直接渲染。
同样，商品销量排行也可以这样聚合：
select product_name, sum(quantity) as sales_count from order_item group by product_id, product_name order by sales_count desc limit 10;统计模块的另一个价值在于“逻辑可解释”。答辩时被问到“经营数据是怎么算出来的”，如果能说清楚SQL里的group by、聚合函数、时间过滤条件，比笼统回答“用Java统计”要专业很多。
4. 前端交互与安全控制
4.1 Thymeleaf模板和静态资源处理
这类毕设项目大多采用服务端渲染，也就是用Thymeleaf做模板，页面上直接通过${}取值、用th:each循环商品列表。好处很明显：不需要单独部署前端工程，SpringBoot项目直接启动，浏览器打开地址就能看到完整页面，非常适合演示。
静态资源放src/main/resources/static下面，css、js、图片按目录分开。模板页面放templates目录。需要注意，Thymeleaf里所有引用静态资源的路径，最好写成th:href="@{/css/style.css}"这样的表达式，让SpringBoot自动拼接上下文路径。
前端页面调试时最影响心情的是浏览器缓存，改完CSS不生效。解决办法一是浏览器开发者工具设置禁用缓存，二是给css引用后面加版本参数，例如@{/css/style.css?v=2}。
4.2 登录拦截器和管理员权限控制
一个合格的商城系统，不能让用户直接输入“/admin”地址就进入后台。需要用拦截器对请求做访问控制。SpringBoot里可以自定义HandlerInterceptor，注册到WebMvcConfigurer里。
public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object userId = request.getSession().getAttribute("userId"); if (userId == null) { response.sendRedirect("/login"); return false; } return true; } }管理端还要额外判断session里的角色标记，只有管理员角色才允许访问/admin/**。很多同学一开始会把静态资源也拦截掉，导致登录页没样式、验证码不显示。解决的常规做法是在注册拦截器时排除/login、/css/**、/js/**、/images/**等路径。
另外，在Controller层直接暴露用户输入的类目查询参数前，先做参数校验会更好。虽然毕设一般不要求那么严格，但“参数校验”和“异常统一处理”是面试和答辩时很加分的话题，值得在项目里体现。
4.3 ECharts图表如何加载异步数据
后台经营分析页面常用ECharts呈现数据。如果直接把统计结果塞在Thymeleaf模板变量里，页面刷新时数据能显示，但图表初始化变得很别扭。更清爽的做法是单独写一个接口返回JSON数据，前端页面加载完成后再用Ajax请求拉取，再交给ECharts渲染。
$(function () { $.getJSON('/admin/statistics/trend', function (res) { var chart = echarts.init(document.getElementById('trendChart')); chart.setOption({ xAxis: { type: 'category', data: res.days }, yAxis: { type: 'value' }, series: [{ type: 'line', data: res.totals }] }); }); });这里有两个细节容易被忽略。第一，返回的days和totals顺序一定要一致，建议在SQL层面就按日期排序。第二，ECharts容器在页面隐藏或宽度为0时，图表尺寸可能计算错误，可以在窗口resize事件里调用chart.resize()，不至于演示时因为窗口缩放导致图表变形。
5. 常见问题与调试心得实录
5.1 环境与配置问题排查
远程调试这类项目，最先遇到的一般不是代码问题，而是环境问题。这里是高频问题汇总：
| 问题现象 | 常见原因 | 处理方式 |
|---|---|---|
| 项目启动端口被占用 | 本地8080被其他程序占用 | 在application.yml改server.port |
| 数据库连接失败 | MySQL版本、账号密码不对 | 核对url、username、password和驱动版本 |
| 数据中文乱码 | 连接串缺少编码参数 | url加useUnicode=true&characterEncoding=utf8 |
| 页面没有样式 | 拦截器拦截了静态资源或路径错误 | 检查注册拦截器时是否排除/css/**/js/** |
| 上传图片失败 | 上传目录不存在或路径权限不足 | 配置文件里指定本地绝对路径并提前创建目录 |
远程调试时，还有一个容易忽略的点：两台电脑连同一个局域网后，如果外网设备访问不了项目，先关掉本机防火墙或放行对应端口，再检查SpringBoot监听的地址是否绑定到所有网卡。默认Tomcat绑定0.0.0.0时通常可以访问，但部分安全软件会拦住入站连接。
5.2 事务不生效与循环依赖问题
事务不生效是我见过最多的问题之一。有时候Service方法明明加了@Transactional，但数据出错了也没有回滚。常见原因包括：自调用，也就是同一个类里的方法调用了另一个事务方法，代理没有进入；还有数据库表引擎不是InnoDB，MySQL默认库虽然可能是InnoDB，但老项目导入时可能保留了MyISAM表，事务自然不生效。
循环依赖在SpringBoot 2.6以后默认禁止Bean之间循环引用。如果你写的Service互相持有对方，启动时报BeanCurrentlyInCreationException，最简单的处理就是拆分职责，或者用构造器注入时调整依赖方向，避免A依赖B、B依赖A。
5.3 答辩演示脚本怎么准备
答辩演示建议走一条主线：用户注册登录 → 浏览分类商品 → 加购两个商品 → 购物车结算 → 模拟支付 → 切换管理员账号 → 后台看到新订单 → 执行发货 → 查看库存预警和销售统计。这条链路把所有模块串在一起，比孤立展示每个页面更有说服力。
演示前把测试商品、测试账号提前准备好，别临场注册用户名输入半天。管理员账号建议提前生成几笔不同状态订单，方便展示报表曲线的效果。另外，把数据库备份文件放一份在答辩电脑上，万一现场数据库被破坏，直接在Navicat里重新导入即可。
5.4 源码和文档的价值不只在于“能跑”
很多同学拿到源码后喜欢直接去改页面样式，这其实是比较低效的方式。源码值钱的地方在于它告诉你一套常见业务系统是怎么组织起来的：先看数据库表关系，再看Controller请求入口，然后看Service的流程编排，最后看前端页面怎么提交表单和展示数据。
如果时间有限，优先改两处最有辨识度的地方：一是商品分类改成本地水族馆相关类目，二是后台首页的统计卡片改成项目名和店铺名。这两处改动影响面小，又能让项目看起来更像自己的东西。
最后说一点经验
我在远程调试这套系统时，印象最深的问题是，很多同学拿到源码的第一反应是“我要加个新功能”，结果在原有代码里到处塞逻辑，最后把事务和库存扣减的地方改乱了。我的建议是先完整跑通一条购物流程，确认每一步的状态变化和数据变化符合预期，再动手加功能。技术栈只是工具，真正能让你在答辩里站住脚的，是你对“顾客从下单到管理员发货，系统里到底发生了什么”的清晰理解。找一个周末，打开数据库，一边看表数据一边跑页面，比复制粘贴一百个代码片段都管用。
