1. 选题论证与系统定位为什么我劝你选酒类商城先说结论在Spring Boot课题满天飞的今天一个平庸的“XX商城系统”确实很难打动答辩评委但把“XX”换成“酒类”整个选题的含金量立刻就不一样了。原因很简单。普通数码商城、服饰商城的商品信息就是“标题价格库存图片”表结构满屏都是教科书模板你做出来和隔壁同学做出来的数据库设计几乎一模一样评委看一眼就失去兴趣。而酒类商品天然自带一批普通商品没有的复杂维度酒精度数、净含量、年份、香型、产地、酿造工艺、适宜场景、保质期。光是商品属性怎么建模就足够你在论文里写出一节有区分度的内容。再说业务场景。酒类销售通常不只是纯零售很多系统还要兼顾会员价、整箱价、批量采购、预售、库存批次管理等逻辑。这意味着订单模块、价格模块、库存模块都有可以深入设计的空间而不是一个简单的CRUD。对毕设来说课题本身的上限决定了论文和系统能展现出的“工作量”酒类商城就是那种不费太多额外功夫、但天然能把工作量撑起来的垂直场景。基于Spring Boot的酒类商城系统整体上应当划分成三类角色普通用户端注册登录、商品浏览与搜索、商品详情、加入购物车、下单支付、订单查询、收货地址管理。后台管理端管理员登录、酒品管理、分类管理、库存管理、订单处理与发货、用户管理、轮播图/公告配置。可选运营端销售统计、热销排行、活动价设置这块可以作为亮点加分项实在时间紧张可以只做简单版。在这个系统里Spring Boot承担的是后端服务层职责负责提供RESTful API处理业务逻辑、访问数据库、校验参数、生成Token等。前端部分你既可以用Vue做一个前后端分离的管理界面也可以直接用Thymeleaf服务端渲染后面我会专门分析两种方案的利弊。一句话总结这个课题的打法酒类商城不是新赛道但“酒类”这个属性足够让系统设计复杂度站在及格线以上。你只需要比普通商城多思考“酒这种商品的特殊性”课题答辩时的底气就会完全不一样。2. 技术选型落地Spring Boot版本与配套框架的取舍技术选型是设计阶段最容易踩坑、也最容易被忽略的一环。很多同学上来就直接“最新版Spring Boot 3.x Spring Security Vue3”一套全上结果开发到一半发现资料查不到、依赖冲突、JDK版本不匹配进度直接卡死。下面是我建议的选型思路和理由。2.1 Spring Boot版本选2.7.x而非3.x先说最关键的版本我用的是Spring Boot 2.7.18。这是2.x系列的最后一个版本也是资料最全、兼容性最好的版本。为什么不用Spring Boot 3.x3.x的确已经发布并成熟但它底层基于Jakarta EE和大量老教程里的javax包不兼容很多早期毕设教程、社区代码段直接跑不通。而且3.x要求JDK 17起不少学校的机房和评阅环境还停留在JDK 8或JDK 11。你答辩要现场部署演示环境兼容性是优先考虑项而不是“新不新”。Spring Boot 2.7.18支持JDK 8启动器和依赖的生态又非常完善在毕设这个场景下就是最优解。2.2 持久层框架选MyBatis-Plus别纠结持久层我强烈建议直接用MyBatis-Plus不要用原生MyBatis更不建议在毕设里用Spring Data JPA。MyBatis-Plus相当于在原生MyBatis上做了大量增强内置通用Mapper、通用Service、自动填充、乐观锁插件、分页插件、代码生成器。你不需要自己写基础的单表CRUD SQL很多代码可以直接生成能把精力省下来去写订单、库存这种真正的业务逻辑。它对答辩也友好——项目里既有手写的XML SQL用于复杂查询又有BaseMapper的常规操作展示技术点的时候“增删改查”和“连表查询”两个维度都占得住。分页插件记得在配置类中显式添加常见代码如下Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }忘记加这个配置的典型症状是selectPage查询返回的 total 总是为 0或分页不生效直接把全表查出来。这些坑后面我会放在实测章节里细讲。2.3 前端方案Vue3前后端分离 vs Thymeleaf服务端渲染这是很多初学者最纠结的选择。我的建议分两种情况如果你有一定前端基础或者愿意花两周补一补Vue基础就选Vue3 Element Plus Axios做前后端分离。前后端分离项目在答辩演示时更“有排面”接口交互、控制台网络请求都能现场展示评委对“前后端分离架构”这个概念也不会有异议。而且这套组合在社区里资料量极大报错基本都能搜到解决方案。如果你几乎没有任何前端经验时间又紧张就选Thymeleaf。它的核心思路是在HTML模板中直接通过th:标签渲染后端数据一个Spring Boot项目就能跑起来不需要单独启动前端工程、不需要处理跨域问题对新手极其友好。缺点是企业里基本不这么用了但你的目标是“完成毕设并通过答辩”Thymeleaf完全够用且不会扣分。我个人带的项目大多选了Vue3前后端分离因为话题多、可展示的内容丰富但如果你连续三天配不好Node环境我劝你果断回头选Thymeleaf这不是退步是止损。2.4 辅助组件Redis、MinIO要加在什么地方Redis在酒类商城系统里建议承担三类任务验证码存储、购物车临时数据和登录Token的管理。验证码5分钟过期这个事天然适合Redis的过期时间购物车数据用Redis的hash结构存key为用户IDfield为商品IDvalue为数量比每次读写MySQL快得多。MinIO则用来做商品图片、酒瓶宣传图、品牌Logo的对象存储。一套完整的商品图设计可以做一个小型图片服务后端只返回URL前端img标签直接引用。MinIO的部署也比较轻量Docker一条命令就能拉起服务毕设里完全够体验一番“独立存储图片”的企业级方案。如果只是想要一个存储传统做法是Spring Boot静态资源映射到本地目录也能实现但“MinIO是加分项静态资源映射是保底项”。3. 数据库设计核心酒类商品的特殊字段与订单状态机数据库设计是一篇毕设论文里最应该被认真对待的部分。系统可以做得简单但表结构要能自圆其说。下面把酒类商城系统的表设计和普通商城的不同点一条条讲清楚。3.1 核心业务表与字段清单一个可答辩的酒类商城系统至少要有以下核心表表名用途关键字段t_user用户表id, username, password(加密), nickname, avatar, phone, create_timet_category酒品分类表id, name(白酒/红酒/啤酒/洋酒…), parent_id, sortt_goods酒品表id, name, category_id, brand, alcohol, volume, vintage, region, price, member_price, stock, sales, cover_img, detail, statust_goods_stock批次库存表可选id, goods_id, batch_no, quantity, remaining, expire_datet_shopping_cart购物车表若用DBid, user_id, goods_id, quantity, checkedt_order订单主表id, order_no, user_id, total_amount, pay_amount, status, address_detail, create_time, pay_time, ship_timet_order_item订单明细表id, order_id, goods_id, goods_name, goods_image, price, quantity, subtotalt_address地址表id, user_id, name, phone, province, city, district, detail, is_defaultt_carousel/t_notice轮播图/公告自行设计即可3.2 酒品表的三个特殊性酒品表必须体现出“酒”的痕迹。以alcohol酒精度数、volume净含量/容量、vintage年份/生产年份、region产区这四件套为例它们是酒类商品的核心参数。白酒用户看香型和度数红酒用户看年份和产区啤酒用户看麦芽浓度洋酒用户看容量规格——不做这些字段的商城本质上只是个“酒瓶子照片墙”。香型和品质这类维度建议采用一个t_goods_attribute扩展表来承载结构为goods_id, attr_name, attr_value比如(1, 香型, 酱香型)、(1, 原料, 高粱/小麦/水)。好处是新增特性不需要频繁改表结构后台管理端可以灵活扩展商品属性论文里可以强调这是“商品属性可配置化设计”。另外酒类商品经常有“整箱优惠”和“单瓶购买”两种场景所以在t_goods里我建议同时设计price单瓶零售价、member_price会员价和case_price整箱价下单时根据用户的购买数量自动匹配价格档位。这就又比普通商城多了一层价格策略逻辑。3.3 订单状态机是必讲内容订单表的核心设计不是字段而是状态流转。标准的订单状态可以枚举为状态值含义可流转至0待支付1已支付、5已取消1已支付/备货中2已发货2已发货3已完成3已完成4申请售后可选4售后中3完成售后5已取消/已关闭无这个状态机的意义在于你在论文里可以明确写出“订单状态通过接口层限定前端不能直接修改状态字段所有状态变更必须走后台service方法”。答辩时评委只要问到“怎么防止用户恶意修改订单状态”你就能从容回答订单状态只由后端业务方法流转接口不提供任意修改状态的能力状态变更都会记录操作日志。3.4 库存与订单明细的防呆设计库存设计上不要只放一个stock整数字段在t_goods里了事。毕设里最简单也最保险的做法是t_goods里维护总库存下单时通过乐观锁更新库存这一点第四章会给出SQL如果还想更进一步就引入批次库存表t_goods_stock支持按批次入库、批次过期管理等场景这在红酒和年份酒合并售卖时是很合理的业务需求。订单明细表必须做“商品信息冗余”。什么是冗余就是在t_order_item里把下单时刻的商品名称、商品图片、下单单价都存一份。原因很实际商品上架后可能改价、改名甚至被删除订单作为历史数据不能跟着变。买家查历史订单时展示的应该是“当时的商品信息”而不是“现在的商品信息”。这个细节很多初学开发想不到但论文里写出来就是加分点。4. 功能链路实现:从用户搜索到下单价款到后台发货系统有了设计接下来就是把核心链路跑通。这一章节不按模块逐一切割而是按一条完整的业务流走一遍用户在商城下单后台如何发货这个过程中Spring Boot背后发生了什么。4.1 用户端主流程搜索、购物车、结算下单先看商品列表。列表页需要支持分类导航、关键词搜索、价格区间筛选、排序销量/价格/新品。这个接口的后端逻辑用MyBatis-Plus的条件构造器写核心代码大致长这样LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); if (StrUtil.isNotBlank(categoryId)) { wrapper.eq(Goods::getCategoryId, categoryId); } if (StrUtil.isNotBlank(keyword)) { wrapper.like(Goods::getName, keyword).or().like(Goods::getBrand, keyword); } if (StrUtil.isNotBlank(orderBy)) { wrapper.last(order by SQLUtil.buildSort(orderBy)); } wrapper.eq(Goods::getStatus, 1); page goodsService.page(new Page(pageNum, pageSize), wrapper);注意搜索关键词这里要防SQL注入wrapper.last()拼接排序字段时一定不要直接拼接前端传来的参数要对字段做白名单校验否则就是容易被攻击的隐患。答辩时这个点如果被问到你可以说“排序字段走白名单映射非法字段直接返回默认排序”。购物车如果选了Redis方案数据结构建议如下# Redis hashkey 为用户IDfield 为商品IDvalue 为数量 HSET cart:1001 5 2 HSET cart:1001 8 1 HINCRBY cart:1001 5 1这样用户每次加购只是一个hash操作结算时批量查询购物车里的商品信息再校验每个商品的状态和库存返回可供结算的商品列表和总价。前端拿到总价后点“提交订单”后端就开始处理真正有技术含量的下单逻辑。4.2 下单与库存更新事务加乐观锁下单是最容易出并发问题的环节。想象一下秒杀瞬间100个用户同时抢同一款限量年份酒如果库存扣减不是原子的数据库就会超卖。最稳妥的方案是“先扣库存、后创建订单”整个流程放在同一个事务方法中。扣库存不用先查再减而是直接用一条带条件的UPDATE完成原子扣减UPDATE t_goods SET stock stock - #{num}, sales sales #{num}, update_time NOW() WHERE id #{goodsId} AND status 1 AND stock #{num}这条SQL的关键在stock #{num}这个条件。如果当前库存小于需求数量受影响行数为0代码里判断rows 0就抛出库存不足的异常整个事务回滚。这种写法没有“先查询再更新”的时间窗口在高并发下也能保证不会超卖是比select update简单可靠很多的做法。这个点放到论文里就是很扎实的“并发控制”章节素材。扣库存成功后再创建订单主表和订单明细表设置初始状态为“待支付”。这里还要考虑一个点金额是否要重新计算而不是信任前端传的total答案是必须后端用库存里的商品单价按购买数量重新计算。4.3 BigDecimal金额计算的正确姿势金额计算是订单链路里最容易出错的地方。Java的float和double在做小数运算时存在精度丢失比如0.1 0.2这样的浮点数会得到一个不精确长尾所以钱的运算绝对不能用浮点类型。所有价格字段在数据库中用DECIMAL(10,2)在Java实体类中用BigDecimal。下单时金额统一按以下方式计算BigDecimal itemPrice goods.getMemberPrice(); // 优先会员价 BigDecimal payAmount itemPrice .multiply(new BigDecimal(num)) .setScale(2, RoundingMode.HALF_UP);千万不要把价格前后端传来传去——前端显示的金额只作为展示参考后端必须根据数据库中的商品价格重新计算。否则用户改一下前端请求体里的金额就等于给自己打折了这是电商系统最基本的安全底线。4.4 后台管理商品上下架与订单处理后台管理端的功能相对直接核心模块是商品管理和订单管理。商品管理要支持新增、编辑、上下架、库存调整。上架时校验关键字段非空名称、度数、容量、价格、库存图片上传到MinIO后回传URL存库。商品列表支持模糊搜索、分类筛选、上下架状态切换。订单管理则围绕订单状态机展开管理员看到“已支付”状态的订单点击发货接口将订单状态更新为“已发货”并记录发货时间及快递单号。处理完的订单就不应该再显示在“待处理”列表里。订单列表建议默认按“创建时间倒序”排列并支持多条件组合查询订单号、用户名、订单状态、下单时间区间。后台权限控制方面登录鉴权我用的是Sa-Token。相比Spring SecuritySa-Token在毕设场景下的优势非常明显注解式鉴权SaCheckLogin、SaCheckRole(admin)比Spring Security那套Filter链和SecurityConfig配置简单太多学习成本低、出bug概率小而且资料也比较新。如果你对Spring Security更熟用那个也没问题但纯从“快速实现一个后台管理系统”的角度讲Sa-Token更省心。4.5 统一返回体与全局异常处理前后端分离模式下所有接口返回统一格式的JSON是规范的基础。建议定义一个ResultT类Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.setCode(200); r.setMessage(success); r.setData(data); return r; } public static T ResultT fail(String message) { ResultT r new Result(); r.setCode(500); r.setMessage(message); return r; } }再配合RestControllerAdvice做全局异常处理把业务异常、参数校验异常、兜底异常分层返回。这样前端接接口时只需要判断code值不用每个接口单独处理异常分支。全局异常没做的话你可能在参数校验失败时看到500和一堆堆栈接口体验会和“半成品”没区别。5. 实测阶段五大坑时差、精度、跨域、静态资源、分页开发调试阶段会有一些项目本身跑通之后才冒出来的问题前前后后占了整个开发周期三分之一的时间。这里直接把高频问题一次讲透你遇到了可以直接对着处理。5.1 插入数据库的时间总是比北京时间慢8小时这个坑非常经典。现象是后端LocalDateTime.now()明明打印的是当前时间但通过MyBatis-Plus插入数据库后create_time字段读出来比北京时间少了8小时。根因是数据库连接URL里没有指定时区MySQL连接器默认取的是服务器系统时区。解决办法是两步JDBC连接URL显式加时区参数jdbc:mysql://localhost:3306/wine_shop?serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf8在application.yml里配置Jackson的时区统一JSON序列化输出spring: jackson: time-zone: GMT8 date-format: yyyy-MM-dd HH:mm:ss两个配置都加上前后端和数据库的时间表现就统一了。只改一个可能还是会出偏差建议一起来。5.2 BigDecimal和前端double类型互转精度丢失前端JavaScript的Number类型是双精度浮点后端返回的BigDecimal金额如果直接序列化前端可能看到199.99999999999997这种诡异数字。解决办法是在JSON序列化配置中统一将BigDecimal转换为字符串Bean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder - { builder.serializerByType(BigDecimal.class, new ToStringSerializer()); }; }这样前端拿到的金额是字符串“199.00”展示时精确无误。涉及金额的字段一律用字符串传输不要在接口里让对方拿浮点数去算钱。5.3 前后端联调跨域与JWT过滤器放行问题前后端分离项目启动后浏览器控制台报跨域错误CORS是最常见的问题。处理方式有几种后端通过WebMvcConfigurer统一添加跨域映射Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(Registry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }同时要注意如果使用了JWT全局过滤器OPTIONS预检请求要放行否则前端发预检请求时会被拦截器直接返回401。登录接口、注册接口、商品列表、商品详情这些公开接口也要在拦截器白名单里放行否则前端一进商城页面就被踢去登录页联调体验极差。5.4 商品图片上传后访问不到这个问题多半出在静态资源映射上。Spring Boot默认只能访问classpath:/static/下的静态文件你上传到本地磁盘D:/wine_shop/upload/的图片并不能直接通过http://localhost:8080/upload/xxx.jpg访问到。需要在配置类里加资源映射Configuration public class WebMvcConfig implements WebMvcConfigurer { Value(${file.upload-path}) private String uploadPath; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/files/**) .addResourceLocations(file: uploadPath); } }uploadPath建议配置成绝对路径例如D:/wine_shop/upload/并确保目录存在。这一坑的典型现象就是上传接口返回成功但浏览器打开图片URL是404。5.5 MyBatis-Plus分页配置漏加导致total恒为0分页插件漏配的表现我在前面已经提到这里补充一个更迷惑的变体分页功能在自己的电脑上好的部署到服务器后查询总数变成0。这通常是因为分页拦截器的数据库类型判断不准。解决办法是在创建PaginationInnerInterceptor时显式指定DbType.MYSQL不要用自动识别。另外Page对象的current和size参数要从前端接收后做边界校验size不要小于1或过大防止用户恶意传入size99999导致大分页查询拖垮数据库。6. 论文与答辩的加分细节系统做完只完成了一半剩下的论文和答辩展示同样重要。这套Spring Boot酒类商城系统如果按下面的思路组织会非常完整。6.1 论文目录结构与写作顺序我建议的论文目录骨架可以自行调整第一章 绪论课题背景与意义、国内外研究现状、论文结构第二章 相关技术介绍Spring Boot框架、MyBatis-Plus、Vue、Redis等第三章 需求分析业务需求、功能需求、非功能需求第四章 系统设计架构设计、功能模块设计、数据库设计第五章 系统实现关键功能页面与核心代码讲解第六章 系统测试功能测试、并发测试、兼容性测试先写“相关技术介绍”和“需求分析”这两个章节难度低、字数容易凑写顺手后再做“系统设计”和“系统实现”最后根据实际完成度认真画用例图、E-R图和时序图。顺序对了写作效率会高很多。6.2 答辩演示脚本怎么设计答辩现场演示系统一定不要漫无目的乱点。建议按下面这个脚本走节奏非常顺打开用户首页演示登录注册可以现场注册一个账号。演示商品浏览按分类筛选点进一个酒品详情页强调商品属性丰富度度数、容量、年份、香型等。加入购物车演示购物车数据交互。提交订单演示支付模拟通常做一个模拟支付按钮状态从待支付变为已支付。切换到管理端演示“待处理订单”如何完成发货。回到用户端演示订单状态随之变化为“已发货”。穿插演示一个自己最熟的代码比如订单事务扣库存那段 SQL 或乐观锁逻辑。整个流程三到五分钟就能结束但把完整的业务闭环走了一遍比零散点页面有用得多。6.3 回答问题的话术与亮点包装答辩环节评委常见问题预先准备“项目里你最有技术含量的地方是什么”回答方向酒品属性可配置化设计加上订单模块的乐观锁扣库存方案说明在并发场景下保证库存不超卖。“为什么选Spring Boot 2.7.x”回答方向生态稳定、资料完备、兼容JDK8环境且2.7.18是2.x最成熟的收官版本不盲目追新是为了项目稳定落地。“库存扣减为什么不需要先查询”回答方向带条件UPDATE是原子操作stock num条件让更新与校验在同一语句中完成不存在“查-改”之间的竞态窗口。“如果用户把前端的订单金额改了怎么办”回答方向后端下单接口不接收前端金额参数实际金额全部由后端根据商品ID和数量重新计算前端金额只做展示。还有一个经验所有亮点代码自己亲手敲出来、亲手改过bug被追问细节时才答得出来。不要背别人的代码去答辩评委追问一个变量为什么这么写你接不住就会非常尴尬。最后说一点我的体会。我见过太多毕业生系统功能做了七八个模块问起来每一个都是“别人写的”“网上找的”最后答辩分数反而不如那些只做了一两个模块、但每个细节都说得头头是道的学生。做这个酒类商城系统的思路也一样与其堆十个功能不如把搜索筛选、下单扣库存、订单状态流转、后台发货这一整条链路彻底做透把它变成真正属于自己的项目。这样不管是毕业答辩还是以后写进简历参加面试你都有拿得出手的硬核内容。