很多同学学完 Java Web 后都有同一种感觉:SpringBoot 能启动、MySQL 增删改查会写、Vue 组件也能照着改,但真要独立做一个带登录、带下单、带后台的完整项目,整个人就懵了。原因不是单个知识点难,而是缺少一条从需求到数据库、再到接口和页面的完整链路。渔鲜小铺销售平台就是为了补上这条链路而存在的。它本质上是一个“卖海鲜的小型电商系统”,复杂度比互联网大厂项目低得多,但业务边界足够清晰,能让你把商品管理、用户注册登录、购物车、下单、库存扣减这些真实场景完整做完。
这套项目由 Java + SpringBoot3 + Vue.js3 + MySQL 构成。SpringBoot3 负责后端接口,Vue3 负责前端页面,MySQL 负责关系型数据存储。相比老的 JSP + Servlet 方案,这种前后端分离结构是当前非常主流的企业开发方式。读完这篇文章,你能得到一套可以直接动手的项目设计思路,包含需求拆分、数据库建表、后端 REST API 编写、Vue3 页面联调、启动验证和问题排查。如果你正在准备毕业设计,或者想从“会语法”过渡到“会做项目”,这篇文章可以作为一份比较完整的地图来用。
下面我不会只讲概念,而是按照一个真实项目的推进顺序来拆:先想清楚业务,再建表,再写后端,再写前端,最后跑通验证。每一段都会给你能直接操作的内容和需要避开的坑。
1. 为什么值得用“渔鲜小铺”练手:业务闭环比技术堆叠更重要
在学习阶段,很多人会陷入一个误区:觉得项目里用的框架越多、中间件越复杂,就越有性价比。于是今天研究消息队列,明天研究分布式事务,恨不得把微服务全家桶都塞进一个小商城。这种做法对初学者其实极其不友好,因为当业务规模还没有达到一定量级时,那些所谓的高并发方案根本体现不出价值,只会让你在概念群里迷失方向。
渔鲜小铺这类项目的好,恰恰在于它的业务复杂度刚刚好。它不是一个只能展示“增删改查”的假项目,而是包含了完整的交易闭环。用户在页面看到商品列表,可以把某个商品加入购物车,可以在购物车中勾选商品进行结算,系统生成订单的同时需要扣减库存,如果库存不足则订单不能创建。这个闭环看起来很熟悉,但里面已经涉及了数据库事务、接口设计、前后端状态同步、异常处理这些真实工程问题。
从商业项目角度看,它也是“B2C 电商”的一个最小可行切片。你如果理解了这张表的订单和订单明细怎么拆,理解了为什么要先锁库存再提交订单,那么以后面对更复杂的电商系统时,思考路径是一样的。这就是我推荐拿它当练手项目的原因:项目表面上叫“销售平台”,实际上是在训练数据建模能力和接口边界意识。技术栈反而只是工具。
另外,这个项目对于求职和答辩也很有说服力。面试官看到“SpringBoot3 + Vue3”这种技术选型,至少知道你没有停留在老旧的 Servlet 阶段。你如果能清楚说出“订单表为什么要拆成主表和明细表”“库存扣减为什么不能只靠前端传数量”“前端代理和后端 CORS 有什么区别”,那已经比大量只背八股文的候选人有区分度。
2. 这套技术栈到底在解决什么问题:SpringBoot3 + Vue3 + MySQL 的角色分工
很多人一上来就写代码,但写之前最好停下来想清楚一个问题:为什么是这三个组件,而不是别的?
从前端用户点击“加入购物车”开始,数据流大概是这样的:浏览器中的 Vue3 页面接收到点击事件,通过 axios 把请求发给后端;后端是 SpringBoot3 应用,它收到 HTTP 请求后先判断登录状态,再调用 Service 层处理业务规则,最后通过 MyBatis-Plus 操作 MySQL 数据库。数据库返回结果后,后端将数据封装成统一的 JSON 结构,传给前端。整个过程跨越了浏览器、Java 服务、数据库三个环节,每个环节都有自己该做的事情。
SpringBoot3 是一个基于 Java 的后端开发框架。它把 Spring 生态中繁琐的配置尽量自动化,让开发者能快速创建可独立运行的 Web 服务。3.x 版本依赖 Spring Framework 6,底层要求 JDK17 起步,这也是很多人升级时主要卡住的地方。相比 SpringBoot2,3.x 整体更新,比如使用 Jakarta EE 命名空间、更好的 GraalVM 原生镜像支持等。如果你现在是新起项目,我认为没有必要再学老版本,直接从 3.x 开始更符合 2025 年之后的主流环境。
Vue.js3 负责前端用户界面。它与 Vue2 的核心差别是组合式 API、更快的响应式系统,以及由 Vite 提供的开发服务器和构建工具。Vite 的启动速度和热更新体验比 Webpack 时代好很多,对学习者也友好。Vue3 中的组件思想很适合电商页面,一个商品卡片可以抽成一个组件,一个购物车列表也可以抽成另一个组件,页面只是不同组件的组合。
MySQL 负责数据持久化。它要存用户信息、商品信息、购物车、订单和订单明细。为什么不用内存 Map 存?因为服务重启后数据会丢失,而且关系型查询和事务能力是业务系统的基石。做电商类项目,库存扣减和订单创建必须能放进同一个数据库事务,这是内存方案无法替代的。
需要注意的是,SpringBoot3、Vue3、MySQL 三者并不是谁依赖谁的关系,而是一种合理的分工协作:后端管理业务规则和数据库读写,前端管理交互和展示,数据库负责最终的数据一致性和持久化。理解这一点,比记住某个注解的用法更重要,因为它决定了你在写代码时会不会把业务规则放错地方。
3. 需求拆分:先搞清楚有哪些角色和功能
写代码前最重要的一步不是打开 IDE,而是把业务需求一条条列出来。渔鲜小铺销售平台围绕“看商品、下单、管库存”三个核心动作展开,主要分为三种角色:游客、普通用户、管理员。
游客只能浏览商品列表,按分类查看海鲜产品。普通用户登录后可以管理购物车、创建订单、查看自己的订单。管理员则进入后台,对商品进行上架、下架、修改库存和价格,也可以查看订单列表。这个功能边界并不复杂,但很符合真实系统的角色职责划分。
| 模块 | 游客 | 普通用户 | 管理员 |
|---|---|---|---|
| 注册/登录 | 可注册 | 可登录 | 可登录 |
| 商品浏览 | 可以 | 可以 | 可以 |
| 购物车操作 | 不可 | 可以 | 不可 |
| 创建订单 | 不可 | 可以 | 不可 |
| 订单管理 | 不可 | 查看个人订单 | 查看全部订单 |
| 商品管理 | 不可 | 不可 | 上架/下架/改价格/改库存 |
除了功能列表,还需要梳理业务规则。很多初学者在建表时不管业务规则,结果到写代码时才发现问题。渔鲜小铺这里有几个比较关键的规则:
第一,商品库存不能扣成负数。用户在提交订单时,后端必须再次检查库存,而不是直接信任前端传入的商品数量。第二,价格必须以数据库里的商品价格为准,不能信任页面传过来的价格,否则用户改一下请求参数就能低价购买。第三,每个订单由订单主表和订单明细表组成。主表存收货人、总金额、订单状态,明细表存每个商品的快照。为什么是快照?因为商品价格和名称可能修改,下单后的历史记录不能被商品表的改动影响。
从开发范围来看,渔鲜小铺完全可以不做“支付”。因为接入真实支付系统需要商户资质,而且对学习后端逻辑没有本质帮助。可以用一个“模拟支付”按钮代替,把订单状态从“待支付”改成“已支付”。这样可以避免法律和资金风险,同时保留了订单状态的流转逻辑。
4. 环境准备:版本兼容是新手第一大坑
很多项目不是代码有 bug,而是环境不兼容导致跑不起来。渔鲜小铺使用 SpringBoot3,项目在环境准备上比传统 JavaWeb 项目有更高要求,我把它单独拿出来讲。
SpringBoot3 强制要求 Java17 或更高版本。如果你电脑里默认装的是 JDK8,直接创建 SpringBoot3 项目会在编译阶段报“不支持发行版本”之类的错误。这一点不像 SpringBoot2 还能勉强用 JDK8,3.x 在字节码级别就不兼容旧版本。我的建议是安装 JDK17,它是目前企业实践中最稳的长期支持版本。如果你愿意尝试新特性,可以装 JDK21,但要注意部分第三方依赖是否已经适配。
数据库方面建议使用 MySQL8.0。MySQL8 默认字符集更合理,支持窗口函数,安全性也更好。虽然 5.7 也能跑这套业务,但新项目不值得