Spring Boot花店商城系统：从数据库设计到订单流程的完整实践

做这行这么多年，Spring Boot 的花店商城系统可以说是毕业设计和课程设计里的“常青树”了。虽然乍一看就是个普通的管理系统，但它的典型程度在于：用户端加管理端、购物车加订单、商品加分类、登录注册加权限控制，电商系统最基础的那套逻辑全都有。不管是想拿来当毕设，还是想自己上手练一遍 Spring Boot 的完整项目流程，这个题目都特别合适。

我见过很多人拿到这类项目第一件事就是急着点 Run，结果不是数据库连不上，就是 Maven 依赖拉不下来，折腾一晚上心态直接崩掉。实际上，这类项目只要把“表结构”和“环境配置”这两块底子打好，后面所有代码写起来都非常顺畅。今天我就把这个商城里里外外拆开来讲清楚，从功能边界到表设计，从环境搭建到调试部署，一条线走完，照着操作基本能顺利跑起来。

1. 花店商城系统的功能边界：用户端与管理端的职责划分

很多人在接触这个项目时容易把“功能多”和“系统好”画等号。但这类网上花店商城的核心，其实不是堆功能，而是把买花的人和卖花的人各自需要做的事情，通过系统清晰地拆成两个不同的操作空间。

1.1 面向普通用户的花店前台

用户端是大部分界面展示和交互逻辑的集中地。这个模块设计得顺不顺，直接影响整套系统是否“看起来像个商城”。

以我做过的花店项目经验来说，用户端核心功能大致可以拆成这几块：

• 用户注册与登录：这里通常不做太复杂的权限框架，但密码的 MD5 加密处理必须要有，不能明文存库。
• 花品浏览与分类筛选：首页展示推荐花品，侧边栏按“鲜花”“绿植”“礼品花束”“永生花”等分类筛选，搜索框支持模糊查询花名或花语。
• 花品详情：展示图片、价格、库存、花语描述，基本就是商品详情页的简化模式。
• 购物车管理：加入购物车、修改数量、删除商品、批量结算。这块的逻辑虽然简单，但涉及前端页面和后台数据的联动。
• 订单提交与模拟支付：用户提交订单后生成订单记录，然后进入一个模拟支付环节，通常就是点一下“确认支付”按钮，把订单状态从“待付款”改成“已付款”。
• 个人中心：查看自己的订单列表、订单详情，确认收货；管理收货地址；修改个人资料和登录密码。
• 公告查看与花材评论：部分系统会带留言板或评价功能，方便用户在购买后晒单或反馈。

这一层需要注意的是：用户的几乎所有操作，都要先判断登录状态。比如点击“加入购物车”，如果当前没有登录用户，可以跳去登录页，也可以做成拦截器统一拦截。这两种手段在实际项目里很常见，我建议学习阶段直接用拦截器，训练“请求先过过滤层再进 Controller”的思路。

1.2 面向管理员的后台管理端

管理端不用像前台那样花里胡哨，要的就是逻辑清楚、操作效率高。通常分以下几块：

• 管理员登录：独立于用户登录的入口，有的项目直接在数据库里单独建一张管理员表。
• 花品管理：花品的增删改查，包括上传花品图片、设置价格和库存、填写花语和描述，以及对上架/下架状态进行维护。
• 分类管理：对花品的分类进行维护，比如新增“节日限定”分类，或修改已有分类名称。
• 订单管理：查看所有用户的订单，按订单状态筛选，进行发货操作，修改订单状态。
• 用户管理：查询用户列表，禁用/解禁异常账号，重置密码。
• 公告管理：发布、修改、删除系统公告，前台首页公告栏会同步显示。
• 轮播图管理（可选）：有一版我做过的是把轮播图做成后台动态配置，前端首页从数据库读取，这样管理员不用改代码就能换推广位图片。

管理端的功能看上去比用户端简单，但其实是“后台管理”这一大类系统的通用范式。如果你以后做任何后台管理系统，这套增删改查的思路都是直接复用的。

1.3 功能设计的两条隐藏底线

第一个隐藏底线：用户端的数据展示要永远考虑到“没有数据”的情况。比如某个分类下暂时没有花，页面要显示“该分类暂无商品”，而不是白屏或报错。很多新手写前端列表时完全不考虑空数据状态，一到演示环节就出丑。

第二个隐藏底线：管理端操作必须有结果反馈。新增、修改、删除之后，要么弹出成功提示，要么页面刷新后立刻看到变化。很多项目的失败感，不是功能没做出来，而是操作完没有任何反馈，用户以为自己点错了。

2. 技术选型的底层逻辑：为什么是 Spring Boot 加这套组合

题目既然是“Springboot 网上花店商城”，那技术上肯定绕不开 Spring Boot。但 Spring Boot 只是一个底座，真正要把项目撑起来，还需要选清楚持久层框架、模板引擎、前端库和数据库，这几样选不好，后面写起来会非常难受。

2.1 持久层框架的选择

目前主流的有 MyBatis、MyBatis-Plus、Spring Data JPA 三种。

我个人的建议：如果是新手、目标是顺利答辩或尽快跑通系统，直接选 MyBatis-Plus，没有悬念。原因很简单：

• 单表 CRUD 完全不用手写 SQL，BaseMapper 里自带 insert、deleteById、selectById、updateById 等方法。
• 条件构造器 QueryWrapper 可以让多条件查询写在 Service 层里，非常直观。
• 分页插件一套配置就能用，配合 Page 对象返回分页数据，比手动拼 LIMIT 舒服太多。

如果是想借这个项目练手、深入理解 SQL 映射，那就用原生 MyBatis，写 XML Mapper 文件，把多表关联查询的 SQL 都亲自写一遍。

这里额外说一句，有些同学会特意选 JPA 来省事，但 JPA 的关联关系在折腾花品表与订单表这种多对多关系时，反而比 MyBatis 更绕，遇到查询报错时排查成本也更高。除非你对 JPA 本身已经足够熟练，否则不推荐在这个项目里给自己加负担。

2.2 前端方案怎么定

前端这块目前常见的做法有三种：

第一，直接用 Thymeleaf 模板引擎，服务端渲染页面。它的好处是 Java 后端和前端页面在同一个工程里，写 Controller 时直接用 ModelAndView 返回视图，学习成本低，也符合题目“单项目”的定位。最初版的花店商城用这个方案最多。

第二，把前端页面做成静态 HTML 加 Vue.js。前后端通过 JSON 接口交互，页面放在 resources/static