基于Spring Boot的小区蔬菜水果商城系统：课设毕设完整项目实战解析

如果你正准备课程设计或者毕业设计，想找一个能跑、能讲、能交差、技术栈还不过时的完整项目，基于Spring Boot的小区蔬菜水果商城系统（也叫蔬菜超市系统）是一个很经典的切入点。这类项目通常自带源码、数据库脚本和万字文档，开箱即可运行，同时对Spring Boot、MyBatis、MySQL、前端页面这些常见考察点都有覆盖。这篇内容我就结合自己带课设和毕业设计的实际经验，把这个课题从技术选型、功能模块、数据库设计、落地配置、常见坑位到答辩准备，从头到尾梳理一遍。你既可以把它当成项目使用说明书，也可以当作二次开发的底稿。

1. 这个项目到底解决什么问题，为什么课设毕设都爱做商城

1.1 一眼看懂系统定位：这不是“超市”，是“蔬菜水果电商”

很多同学拿到题目第一反应是做一个收银系统，这是个误区。题目里写的是“小区蔬菜水果商城系统”或“蔬菜超市系统”，核心并不在收银台，而在于“网上商城”这条完整链路：用户在小程序或网页上浏览蔬菜水果、查看详情、加入购物车、下单、选择收货地址、模拟支付，然后小区管理员或商家在后台管理商品、处理订单、更新配送状态。

它的业务价值可以理解为“社区版生鲜电商”。跟淘宝这类大平台比，它的业务范围小但五脏俱全，非常适合用来展示一个学生的全栈能力。对课程设计来说，系统要能跑、功能别太少、结构别太乱；对毕业设计来说，还要能体现你对业务建模、数据库设计、权限控制、订单状态流转这些问题的理解。商城类项目天然满足这些要求，这也是为什么每届都能看到大量果蔬商城、零食商城、二手商城的原因。

1.2 为什么Spring Boot是这类项目的稳妥选择

从技术选型角度看，基于Spring Boot做商城是“性价比最高”的方案之一。原因很实在：

第一，Spring Boot降低了配置成本。传统的SSM项目要写一堆XML配置，光是spring、mybatis、数据源的配置文件就能劝退一拨人。Spring Boot靠自动配置和起步依赖把大部分配置收敛到了application.yml里，开发省事，演示也更稳定。

第二，自带内嵌Tomcat。启动时直接运行main方法，不需要单独安装部署容器，部署演示的运维成本几乎为零，这在答辩现场非常重要。你不可能在老师面前花十分钟去配Tomcat。

第三，生态成熟。MyBatis、MyBatis-Plus、Spring Security、JWT、Redis都能无缝集成，哪怕以后做简历上的项目延伸，这个底子也不会白打。

当然，用更重的微服务架构做“小区果蔬商城”是杀鸡用牛刀，复杂不说，答辩时还得解释为什么这么设计。单体应用在这里反而是优点：逻辑清晰、部署简单、架构一目了然。

1.3 自带源码、数据库和万字文档，到底意味着什么

标题强调“附源码、数据库、万字文档”，这不是一句废话，背后是三类可以直接交付的资产。

• 源码：省去了从零搭建工程的时间，给你一个可运行、可修改的起点。
• 数据库：说明不止有表结构，还有建表SQL和初始数据，商品分类、用户、订单状态都能直接演示。
• 万字文档：覆盖需求分析、系统设计、数据库设计、系统实现、测试等章节，对应学校要求的设计说明书或毕业论文模板。

我见过很多同学拿到这个资源包以后第一反应是“直接跑起来就完事”，这是最吃亏的。源码、数据库、文档这三件事，本质上是给你边界清晰的“半成品”，你需要做的是真正理解它、复现它、再根据自己的理解改动它。后面我会专门讲怎么“安全地魔改”而不翻车。

2. 技术栈拆解：上手前先弄懂每层在干什么

2.1 后端与持久层：Spring Boot + MyBatis-Plus是黄金组合

大多数此类课设项目使用的后端组合是：Spring Boot + MyBatis或MyBatis-Plus + MySQL。这里有个细节值得注意：MyBatis-Plus在课程设计项目中越来越常见，因为它提供了BaseMapper和QueryWrapper，单表增删改查基本不用写SQL，能大幅提高开发效率。

你如果之前学的是MyBatis XML写法，看到项目里一堆Mapper接口没有XML可能会懵。其实MyBatis-Plus就像“增强版MyBatis”，大部分简单SQL由框架自动生成，只有复杂统计、联表查询时才可能需要手写。判断一个项目用的是哪套，看pom.xml里引的依赖名称和注释就知道。

持久层在MVC三层结构中的位置也很明确：Controller负责接收前端请求并调度，Service负责业务逻辑（比如下单时要同时操作订单表和明细表），Mapper/DAO负责数据库读写。课设项目的核心也不复杂，你把“用户下单”这个链路里的三张表怎么联动讲明白，就已经比一半同学强了。

2.2 前端展示与交互：模板渲染和前后端分离怎么选

这类系统前端常见两种实现方式。

一种是使用Thymeleaf模板引擎，搭配Bootstrap或LayUI等前端框架。Thymeleaf直接集成在Spring Boot项目中，Controller把业务数据放到Model里，页面通过th:each、th:if这个风格渲染。这种方式的好处是课程设计结构简单，部署时一个jar包搞定，答辩演示也不容易出幺蛾子。项目里如果看到templates目录下的HTML文件带th:开头属性，基本就是这个方案。

另一种是前后端分离：Vue + Element UI + Axios，后端单独提供REST接口，前端通过npm工程独立运行。这种方案视觉效果更现代，但部署时需要同时启动前后端两个服务，如果前端静态资源没有打进Spring Boot工程，演示现场可能出现“后端通了前端白屏”的尴尬。

我的建议很直白：如果是课设，优先选模板渲染方案的源码，因为稳；如果毕设想写更“现代化”一点，至少提前确认前端dist目录能否被Spring Boot正确托管，最好在演示前把前后端打包成同源访问。

2.3 手里只有Jar包？反编译还原成工程的基本思路

有些同学拿到手的不是源码，而是一个可运行的jar包。这时候就需要用反编译手段还原成可阅读、可改动的工程。很多人以为这是“破解”，其实反编译主要用途是学习别人的实现、梳理代码结构，只要用途正当就没问题。

操作思路大致是：先确认项目基于Java 8还是11，然后使用IDEA自带的Java Decompiler插件，或者下载Fernflower/CFR工具，把jar包里的.class文件还原成.java源文件。还原后会得到Controller、Service、实体类这些核心代码，但resources目录里的静态资源、application.yml、pom.xml大概率需要自己重建，因为有些文件不打进jar包或在反编译后结构不完整。

实操中比较省事的做法是：反编译源码后用IDEA新建一个Spring Boot工程，把还原的java文件按controller/service/mapper/entity/pojo分类放到对应包下，再手动补回pom.xml和resources目录。这个过程等于强制你在“重写”一遍项目，对理解整个系统帮助非常大。反编译代码通常没有注释，所以一些关键业务逻辑还要结合数据库脚本和文档一起看，才不会跑偏。

3. 功能模块梳理：从注册下单到后台发货的全流程

3.1 用户端重点功能：商品浏览、购物车、订单关键链路

用户端是系统面向消费者的一半，也是答辩演示的“主舞台”。核心功能拆开看，大概是以下几个环节：

• 用户注册与登录：注册时填写用户名、密码、手机号等基础信息，登录后状态保存在Session或Token中。大部分课设项目用Session会话配合拦截器做登录检查，简单直观。
• 商品展示与搜索：首页按蔬菜、水果、肉类等分类展示轮播图或商品卡片，支持关键字搜索。高级一点的会按销量、价格、上架时间排序。这是体现查询能力和SQL功底的地方。
• 商品详情页：展示价格、库存、单位（比如“斤”“盒”）、描述图片。这里的核心逻辑是库存与上下架状态，下架商品要能正确隐藏。
• 购物车：把商品加入购物车、修改数量、删除商品、计算合计金额。这个模块的实现方式差异很大，后面我在数据库设计部分会解释Session方案和数据库表的区别。
• 下单与模拟支付：确定收货地址，生成订单，订单状态变为“待支付”，点击支付按钮后状态改为“待发货”。这里核心难点在于订单表与订单明细表必须同时写入，一旦中途失败要能回滚。也正因为如此，@Transactional是这部分的关键注解，也是老师最爱问的点。
• 订单查看与取消：用户查看自己历史订单，未支付订单可以取消。如果已经支付，退货流程在课设里通常简化成申请退款或者不处理。

一个能顺利演示的标准链路是：注册新用户——搜索土豆——加入购物车——购物车变更数量——下单并支付——在“我的订单”里看到状态变化——后台发货后用户看到“已发货”。这条线走通，系统的主体功能就证明没问题了。

3.2 后台管理功能：商品、分类、订单、用户四大板块

后台管理系统是一般学生容易忽略但绝对重要的部分，它解决“店老板怎么维护商品、怎么处理订单”的问题。没有后台，你演示时就只能写SQL硬改数据，非常被动。

典型后台板块如下：

• 商品管理：新增、编辑、删除商品，修改价格库存，上传商品图片，上下架。需要重点处理图片上传后的保存路径和访问路径，很多项目图片404的坑都出现在这里。
• 分类管理：维护蔬菜、水果、肉禽蛋这些分类，商品列表能按分类筛选。这里要防止删除“仍有商品关联”的分类，否则会出现脏数据。
• 订单管理：查看全部订单并按其状态筛选，实现发货或取消操作。核心逻辑是订单状态只能按照合法路径流转——待支付可以取消，已支付可以发货，发货后可以完成。
• 用户管理：查看注册用户列表，对异常用户禁用或删除。这里涉及外键连带数据，处理时要注意不能误伤用户的订单记录。

后台的权限控制一般通过角色字段区分，管理员登录后进入/admin路径，普通用户访问时被拦截或返回403。这一点要能向老师说清楚“用什么机制防止普通用户直接访问后台URL”。

3.3 权限与会话控制：普通用户和管理员如何分开

权限分离看起来只是“登录检查”，但实现方案能体现你对Web基础的理解深度。

多数课设项目采用的做法是：定义一个拦截器（HandlerInterceptor），在preHandle方法里判断当前请求路径是否为后台路径。如果是后台路径，再检查当前Session里是否有管理员身份；如果没有就重定向到管理员登录页。同样，用户端访问个人订单、购物车结算页面时也需要类似拦截。

有的项目引入了Spring Security或Shiro，功能更强但学习曲线陡峭。如果你只是想把项目跑起来后通过答辩，自定义拦截器已经足够，而且更好讲清楚。真正的加分项是你清楚“哪些页面必须放行”——登录页、注册页、商品浏览首页必须放行，后台管理和个人中心必须拦截。

4. 数据库设计：几张核心表的关系才是项目的灵魂

4.1 核心实体与关联关系：用户、商品、订单、明细

判断一个商城数据库是否合理的简单方法，是看它有没有以下这张“表关系图”：

• 用户表（user）：主键id、用户名、密码、手机号、创建时间。
• 商品分类表（category）：分类id、分类名称、排序、是否显示。
• 商品表（product）：商品id、分类id、商品名称、图片、价格、库存、单位、描述、上架状态。
• 购物车表（cart）：若用数据库存储购物车，则包含id、用户id、商品id、数量；若用Session存储，这一张表可有可无。
• 地址表（address）：id、用户id、收货人、联系电话、详细地址、是否默认。
• 订单表（orders）：id、订单编号、用户id、下单时间、总金额、收货人信息、订单状态。
• 订单明细表（order_detail）：id、订单id、商品id、商品名称、商品图片、单价、数量、小计。

这里最关键的一条关系是订单和订单明细的一对多关系。一笔订单可能包含三样商品，不能把三种商品直接塞同一行，所以拆分成主表和子表。数据库要能实现“按订单查明细、按用户查订单”，所有核心业务都建立在这两张表上。

4.2 字段设计的几个关键规范：金额、状态、时间、索引

不要小看建表字段，这里藏着老师喜欢追问的细节。

金额字段必须用decimal，不要用double或float。二进制浮点数在计算金额时存在精度问题，0.1 + 0.2并不完全等于0.3，超市系统一旦金额算错很难解释。decimal(10,2)能保留两位小数，绝大多数场景够用。如果你技术不错，还可以在VARCHAR字段用分存储金额，但那不是课设标准做法。

价格字段也可以拆成“原价”和“售价”两列，用来做打折功能。如果只显示一个价格，这个功能就废了。

订单状态字段可以用int或varchar，但含义要在设计文档里写清楚。比如0待支付、1待发货、2已发货、3已完成、4已取消。状态字段的流转逻辑必须和代码一致，否则会出现“订单状态显示混乱”这类硬伤。

时间字段统一用datetime，不要用timestamp。datetime可读性更好，范围更大，更适合课设演示和做表格筛选。数据库默认当前时间可以设置DEFAULT CURRENT_TIMESTAMP，这样插入订单不用专门传时间。

索引方面至少要有两个：订单表(user_id)索引，用于查询用户订单；订单明细表(order_id)索引，用于反查订单内容。商品表如果经常按名称搜索，给商品名建立普通索引也可以。但课设项目数据量小，过度建索引毫无意义。

4.3 建表目录与初始化数据，直接抄作业

一个完整建表SQL的思路可以用下面的简化和示意来说明。实际项目里需要在每个字段后补充注释，这样将来写数据库设计文档时可以直接复用。

CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '用户ID', username VARCHAR(50) NOT NULL COMMENT '用户名', password VARCHAR(100) NOT NULL COMMENT '密码（建议MD5加密）', phone VARCHAR(20) COMMENT '手机号', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

同样逻辑下，product表里会有category_id、price、stock、unit等字段；orders表里会有order_no、user_id、total_amount、status等字段。所有核心表统一使用InnoDB引擎、utf8mb4字符集，目的是支持中文存储和事务操作。

初始化数据这块，建议给分类表插入“蔬菜”“水果”“肉禽蛋”“米面粮油”几条基础分类；给商品表插入十几条带中文名称和价格的数据；给管理员表插入一个固定账号，比如admin/123456或sysadmin/123456，具体以项目文档为准。这样项目第一次启动就有完整可看的内容，不用临时补数据。

数据库导入时推荐用Navicat手动运行SQL文件，并确认编码为UTF-8。直接命令行导入容易出现中文乱码，尤其MySQL5.7版本下如果不显式加--default-character-set=utf8mb4，很容易把商品名称全部变成“？”。这也是老手都会刻意检查的一步。

5. 环境搭建与项目启动实操：从导入源码到跑起来

5.1 环境准备清单：JDK、Maven、MySQL、IDEA

跑一个Spring Boot商城项目，本地环境只需要四样：JDK、Maven、MySQL、IDEA。

• JDK版本：看pom.xml里的java.version配置，一般是1.8或11。Spring Boot 2.x系列配JDK8最常见，Spring Boot 3.x强制JDK17。版本不匹配时项目根本启动不了，这是最乏味但最常见的错误。
• Maven：项目用的是Maven构建，IDEA自带Maven可以凑合用，但建议单独安装并设置好阿里云镜像。没有镜像时，首次拉取依赖可能要几十分钟甚至失败。
• MySQL：5.7和8.0都可以，但数据库连接驱动和时区参数有差异。MySQL8.0的驱动用的是com.mysql.cj.jdbc.Driver，MySQL5.7一般用com.mysql.jdbc.Driver。导入SQL后用Navicat先连接测试，再关闭项目里多余连接池。
• IDEA：社区版就够用，但需要确认安装了Lombok插件。项目里大量使用@Data注解简化实体类，没有Lombok插件，代码会大面积标红且编译失败。

5.2 导入项目并修改配置文件的关键坑位

导入项目时不要用“New Project”操作，要选“Open”，找到源码目录下的pom.xml打开，IDEA才能识别为Maven工程。首次导入会自动下载依赖，右下角进度条走完之前不要写代码，也不要动pom.xml。

项目能正常识别之后，优先打开application.yml或application.properties文件。里面最需要改的是数据源配置：

spring: datasource: url: jdbc:mysql://localhost:3306/vegetable_market?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456

注意url里的数据库名必须和你实际建的库名一致。serverTimezone=Asia/Shanghai可以解决MySQL8时报时区错误的问题。username和password改成你自己本机的MySQL账号。改错这一步，后面怎么启动都会连不上库。

另一个需要留意的配置是服务器端口和上下文路径。如果端口是8080，启动后访问http://localhost:8080即可。如果出现“Port 8080 was already in use”，说明有其他程序占用端口，可以用netstat -ano | findstr 8080找到占用进程后关闭，也可以在配置里把端口改成8081或8090。

5.3 运行、演示与交付：一场顺利演示需要提前做的事情

配置完成后启动项目，成功标志是日志中看到“Started XxxApplication in x.x seconds”且没有红色异常。之后打开浏览器访问首页。

想要演示不翻车，建议提前做三件事：

第一，把初始账号列出来。管理员账号通常写在SQL或文档中，先确认密码。如果默认密码在代码里以MD5形式保存，而管理员表里又是明文，登录会出现密码错误，需要去表里手动UPDATE成程序所期望的加密值。

第二，准备至少一个“完整可跑业务链”的演示数据。给某款商品设置正常的价格库存，准备一个收货地址，然后从注册登录、选商品、加购物车、下单、支付到后台发货，完整走一遍，确保没有隐藏报错。

第三，检查商品图片资源。图片如果存在本地static/upload目录，换电脑部署时也要一起拷贝；如果存在数据库或OOS路径，得保证网络能正常访问。否则页面上所有商品都裂图，演示效果会非常减分。

6. 常见问题与排查技巧：启动报错别慌，按这个表来

6.1 最高频的十个报错现象与解决方案

下面按故障现象、原因和解决方式整理成速查表，这些都是我见过项目跑不起来时的高频原因。

这十类问题覆盖了90%的启动故障。很多人遇到报错就上来重装环境，这是非常低效的。观察日志第一行中文或英文描述，再对应到可能出问题的环节，其实解决起来非常快。

6.2 通用排查方法论：三层递进看问题

如果上面的表没覆盖到你的问题，可以用一个三层递进的排查思路。

第一层，看有没有编译错误。IDEA底部“Build”窗口如果有红色日志，先编译过了再说。很多类是手工程拷贝进去但找不到，可能是因为模块结构混乱，重新Maven Reimport一下就能解决。

第二层，启动时看Spring容器日志。日志会告诉你哪一步初始化失败。数据库连不上、Redis未启动、Tomcat端口冲突都会在这个阶段暴露。对应到类就是@Configuration类实例化时出错。

第三层，运行时看接口报错。项目启动了但下单失败，此时打开浏览器开发者工具F12，看Network里的请求状态码。500错误说明后端有异常，需要去后台日志里复制异常栈，重点看有无Mapper方法找不到、空指针、SQL语法错误。404说明访问路径错误或Controller没有对应映射。

这套思路比瞎搜复制粘贴一百个“解决方案”靠谱得多。

7. 把“别人的系统”变成“自己的系统”：适配与扩展

7.1 低成本改造成自己的系统：改名、改包装、改界面

拿到别人源码后如果原封不动导给老师，那跟抄袭的区别不大，老师也不傻。最简单又最有效的改造是三件事。

改名是非常必要的。项目里所有Controller类、页面标题、导航栏、登录框里的系统名称，都改成比如“幸福小区果蔬商城”这种个性化名称。不要只改浏览器页签标题，要把页面上的品牌名、主页logo文字、后台系统的欢迎语全部一致化，才自然。

改包名和artifactId。在IDEA中右击包目录，Refactor -> Rename，可以把com.example.demo这类默认包结构改成你自己的域名反转加项目名。这一步技术含量不高但需要谨慎，因为包名被大量import引用，改动后要确保全局引用的类路径同步更新。稳妥一点的做法是改完包名后执行mvn clean compile，编译通过再运行。

改数据库名。把SQL文件里的数据库名和application.yml连接串中的数据库名改为你自己的名字，比如from vegetable_market to vegetable_shop_xxx。启动前先在Navicat新建同名库再导入。

界面样式如果你不熟前端，不必大动页面布局，只要把主题色、首页轮播图、商品图片换成跟自己场景匹配的内容即可。这样整系统看起来是“为你这个小区的菜店”定制的。

7.2 低成本加分功能：推荐几个性价比高的扩展点

毕设竞争激烈，课设如果学有余力，加一两个扩展功能，答辩时语气都不一样。下面几个功能实现成本低但效果明显：

一个是搜索增强。原项目可能只支持按商品名模糊搜索，你可以加“按分类筛选+按价格区间筛选+按销量排序”，实现就是几条SQL查询语句的事，但讲起来可以是“多条件组合查询”。

另一个是商品热销排行。列表页展示销量前N名商品，在订单明细表里按商品id做SUM查询即可。这个功能需要订单有“已完成”状态才比较有意义，否则没有销量数据可以展示。

还有一个是简单图表统计。后台首页展示柱状图或折线图，显示近七天订单量和销售额。数据库里只需要查下单时间范围和SUM(total_amount)即可。图表可以用ECharts官方示例改，不复杂，但视觉加分非常明显。

如果你拿到的是带图片本地存储的项目，还可以尝试把它扩展为MinIO对象存储，这样图片管理更接近企业级做法。但要注意这个扩展会增加运维复杂度，如果本地没有可用的MinIO服务就得不偿失，建议只写进文档的“改进与展望”章节即可。

7.3 能讲清楚比代码多更重要：核心代码阅读路线

答辩最怕的就是老师随机点一个类，你完全不知道它在干什么。这不是班主任罚你，而是考察你到底有没有真正跑通并读懂了项目。我建议按下面这条路线读代码，顺序比数量更重要。

先读实体类。一张表对应一个实体类，字段类型和数据表一致。看懂实体类的基本含义后，数据库设计文档就赢了一半。

再读Controller层。每个Controller对应一个功能的URL入口。点进去看方法注解，比如@PostMapping("/order/create")，一眼就能看出这是下单入口，方法里会干净地调用Service中的createOrder方法。

之后读Service层。这是业务核心。重点看createOrder或者addOrder是怎么同时写入订单表和明细表的，注释有没有@Transactional，方法内部有几个Mapper调用，这直接决定了事务边界是否合理。

最后再看Mapper层。如果是MyBatis-Plus，绝大多数方法就是继承BaseMapper后的直接调用；如果手写了复杂SQL，方法上会标注@Select、@Update注解，或者对应XML里有一段SQL。读到这里，整个用户下单流程在你脑子里就是一个从页面到数据库的完整调用链了。

8. 万字文档与答辩准备：让项目真正立得住

8.1 文档结构：按学校模板拆出来的七个章节

资源包里所说的万字文档，一般已经是结构完整的设计说明书。但老师不只看文档有没有文字量，还要看是否符合论文写作套路。一套标准的Spring Boot商城项目文档大概是这样排的：

• 摘要与目录：说清项目做什么、用什么技术、达到什么效果，中文摘要通常300字左右，关键词列出Spring Boot、MySQL、商城系统等。
• 绪论：介绍小区果蔬商城系统的开发背景和意义，同时交代国内外电商系统的发展现状。
• 需求分析：用功能需求和非功能需求来描述系统要做什么，配合用例图说明普通用户与管理员各自能操作哪些内容。
• 系统设计：总体架构图、功能模块划分、业务流程设计。重点是下单流程和后台订单处理流程图，文字配合截图说明即可。
• 数据库设计：E-R图、数据表清单、核心表结构说明。要写清楚订单与订单明细为什么拆分，商品与分类为什么是一对多。
• 系统实现：按功能模块截图配合关键代码展示。代码不要贴大段源码，选一个核心方法重点分析。
• 系统测试与总结：给出测试用例表格，包括正常流程和异常流程，再写项目不足与展望。

如果你自己写了扩展功能，一定要在“系统设计”和“系统实现”两个章节里同步补充对应文字，不能前面分布式后面功能表里没有。

8.2 答辩演示脚本与高频问题应对

答辩现场最尴尬的情况不是被问倒，而是“无处可演示”。提前写好一个五到八分钟的演示脚本，可以避免冷场。

演示顺序我建议这样安排：先跑首页并介绍整体定位，然后切换两个角色——先以普通用户身份走一遍“搜索商品-加入购物车-下单-支付”，再切管理员后台处理订单发货，最后打开一个数据库表展示订单数据如何变化。这样整个过程既有页面视角，又有数据视角，说明系统不是“界面假能跑，数据库空空如也”。

高频答辩问题提前准备好，能做到脱口而出：

• 为什么选Spring Boot？答：简化配置、内嵌Tomcat、快速构建单体应用，适合中小型系统。
• 购物车是怎么实现的？答：用Session或数据库表保存临时商品数据，核心方法是添加商品时判断是否已存在，存在就累加数量，否则新增一条记录。
• 下单时如何保证数据一致性？答：在Service层下单方法上加@Transactional，保证订单表和订单明细表要么同时成功，要么同时回滚。
• 用户密码怎么保存？答：用MD5加密，防止明文存储在数据库泄露风险。这里顺便说清项目中是调用工具类还是SQL函数加密。
• 这个系统有什么不足？答：没有接入真实的在线支付、没有消息队列、图片存储用的本地磁盘。选两三条客观陈述即可，别说系统没有缺点。

我另外有一个小习惯，会在答辩前把两个状态机画在草稿纸上：订单状态何时从待支付到待发货，用户在系统中看到的信息如何随状态变化。这个问题被追问的概率非常高，你心里有数，思路就不会断。

最后说点实在的。我带过的课设项目里，最普遍的情况是：一开始只想着把系统跑起来，到答辩前一周才开始认真看代码。真正让你顺利通过的不是系统界面有多炫，而是你能不能清楚说明表结构、用户下单链路和几个关键类到底做了什么。这套资源给了你一个完整且可复现的起点，但最终成绩的高度，取决于你愿不愿意多花几个晚上把Controller、Service、Mapper之间的调用关系理清，再顺手加上一两个属于自己的小功能。到那时，这个项目就不再只是“交差作业”，而是一段可以写进简历的真实项目经历了。与其焦虑，不如今天就把它跑起来，再沿着订单这条链路，把每一行关键代码读到自己能讲明白为止。