每年三四月份，总有一批计算机专业的同学对着毕业设计选题发愁。Java方向绕不开Spring Boot，商城系统又是永远的“经典款”，但纯做电商又容易被老师一句“没有新意”打回来。这个题目——“基于Spring Boot框架的南京特色美食小吃商城系统”，其实是一条很聪明的差异化路线：技术栈是标准的Java Spring Boot商城套路，业务场景却换成了有地域特色、有文化故事、有实物依托的南京美食，既保住了技术含量，又让论文和演示都有了话题性。文章配套源码加论文，对于想快速搞定毕设、又想真正讲清楚系统逻辑的同学来说，参考价值非常高。
这篇内容我会从项目定位、功能模块、数据库设计、核心代码实现、常见坑点、论文与答辩准备这几个维度完整拆一遍，尽量把“为什么这么做”也讲透，而不只是贴代码。打算做类似选题，或者想把它扩展成自己版本的商城项目的，可以直接照着往下走。
1. 为什么这个选题值得做：定位与整体设计思路
1.1 选题角度的差异化打法
先聊选题思路。商城系统每年毕业设计做的人很多，但如果题目是“超市电商平台”“二手交易系统”，老师大概率审美疲劳。换成“南京特色美食小吃商城”，视角一下子就不一样了：它本质上还是一个通用商城，但商品是鸭血粉丝汤、盐水鸭、桂花糖芋苗、牛肉锅贴、糕团这类有明确地域属性的东西，这意味着系统里可以自然地加入分类专题、地域文化介绍、销量排行、套餐推荐等功能，展示出来的效果比“商品A、商品B”生动得多。
差异化带来的直接好处有三个：第一，论文里的“选题背景”和“需求分析”好写，南京旅游餐饮背景随手就能铺开，不需要硬编；第二，系统演示环节有画面感，评委对页面里的美食图片和分类会有兴趣，问答环节更容易往业务逻辑上引导；第三，扩展空间大，后续想做推荐算法、做软文营销模块、做用户点评社区，都可以在美食这个场景里说得通。核心逻辑没变，但包装变好了。
1.2 技术栈选型：生态成熟、能打能讲
这个项目用的主框架是Spring Boot，配套的持久层框架建议用MyBatis或MyBatis-Plus，数据库用MySQL，前端可以采用Thymeleaf服务端渲染，也可以拆出Vue做前后端分离。选这套组合的原因是它高度匹配国内Java岗位的实际使用习惯，毕设做完之后，简历上写的“熟悉Spring Boot、MyBatis、MySQL”，面试时是经得起追问的。
具体到版本，Spring Boot 2.x系列是最稳妥的选择，因为网上资料最多，和MyBatis-Plus、JWT、Swagger的兼容性都验证过。如果去追最新的Spring Boot 3.x，虽然功能新，但Jakarta命名空间切换、部分starter的兼容问题会让新手卡很久。做毕设讲究“稳”，不追求最新。我用Spring Boot 2.7.x为例，Maven管理依赖，JDK 1.8或11均可，这个组合在绝大多数实验室电脑上都能跑起来。
1.3 商城系统的业务闭环设计
一个能说服评委的商城，业务闭环必须完整。用户从注册登录开始，浏览分类商品，把小吃加入购物车，提交订单，选择收货地址，完成支付（毕设里一般是模拟支付），然后商家在后台发货，用户确认收货后可以评价。这个链路缺了任何一环，都会被问“那你这个商城怎么卖东西”这类问题。
这个项目我建议把用户端和管理端拆开设计。用户端面向消费者，核心是购物体验；管理端面向运营人员，核心是商品上下架、订单处理和数据分析。两个端共用同一套数据库，只是接口和权限不同。用Spring Boot实现起来，管理端可以走独立的Controller包，登录用JWT区分角色权限，整体结构清晰，答辩时也好讲。
2. 功能模块拆解与数据库设计
2.1 用户端功能清单
用户端的功能，我按一个正常点外卖或者买特产小吃的流程来规划：
- 注册与登录：手机号或用户名注册，密码用MD5加盐或BCrypt加密存储，登录后发放JWT令牌。
- 商品浏览：首页轮播图推荐、分类列表（秦淮经典、传统糕点、特色卤味等）、商品搜索。
- 商品详情：展示图文介绍、价格、库存、销量、评价列表。
- 购物车：加入、修改数量、删除、勾选结算，购物车数据存入数据库而不是浏览器LocalStorage，这样多端同步才有说服力。
- 订单管理：生成订单、查看订单列表、取消订单、确认收货。
- 支付模拟：对接支付宝比较麻烦，毕设项目一般做一个模拟支付的页面，点击“立即支付”后把订单状态从待付款改成待发货。
- 评价管理：确认收货后可以对商品打分和写评论，评论显示在商品详情页。
2.2 管理端功能清单
管理端是体现系统完整性的重点，别只做增删改查，加一点统计数据会明显提升档次：
- 管理员权限控制：登录拦截器判断JWT中角色，普通用户不可访问后台接口。
- 商品管理：新增、编辑、上下架商品，上传商品图（图片保存到本地上传目录，数据库存相对路径）。
- 分类管理：维护商品分类，比如“金陵菜肴”“风味小吃”“传统糕点”“特色礼盒”。
- 订单管理：查看所有订单，按状态筛选，执行发货、完成退款等操作。
- 用户管理：查询用户列表、启用或禁用账号。
- 数据统计：首页展示今日订单数、销售额、商品总数、用户总数，用ECharts画一个近七日的销量折线图，这属于论文里能截图的核心亮点。
2.3 核心表结构设计
数据库命名清晰、字段规范，会让论文的ER图很好画。我实际使用的核心表大致如下：
用户表（tb_user）：id、username、password、phone、avatar、role（区分USER和ADMIN）、status、create_time。角色字段必须有，没有这个，后台权限拦不住。
商品分类表（tb_category）：id、name、sort、create_time。建议预先加sort排序字段，前端分类展示会稳定很多，否则列表乱序很尴尬。
商品信息表（tb_product）：id、category_id、name、sub_title、main_image、detail（富文本详情）、price、stock、sales、status、create_time。price建议用DECIMAL(10,2)，不要用float，否则精度问题会让你在订单金额计算上吃亏。
购物车表（tb_cart）：id、user_id、product_id、quantity、checked_status。每个用户和商品唯一，可以加唯一索引(user_id, product_id)。
订单主表（tb_order）：id、order_no（订单编号）、user_id、total_price、status（0待付款、1待发货、2待收货、3已完成、4已取消）、receiver_name、receiver_phone、receiver_address、create_time、pay_time、ship_time、finish_time。字段设计成带状态变化时间的，后面统计“哪个环节最耗时”就能直接用。
订单明细表（tb_order_item）：id、order_id、product_id、product_name、product_image、price、quantity。为什么要冗余商品名称和图片？因为商品信息可能被修改或删除，订单历史必须保留“当时买的是什么”。
评价表（tb_comment）：id、product_id、user_id、content、score、create_time。
设计这些表时有一个核心原则：订单相关的数据要保证历史快照，不能完全依赖关联查询商品表，否则商品改名或删除后订单看起来会缺东西。这是做商城的常识，提前做进去，论文里还可以写一笔。
2.4 数据库设计的取舍与规范
实际建表的时候，新手容易犯的毛病是字段类型乱用、没有外键逻辑、时间字段不统一。我个人的习惯是时间字段统一用datetime，主键用bigint自增，金额用decimal，状态用tinyint加注释。外键我建议不加物理外键，而是通过业务代码控制关联，理由是Spring Boot项目后期做数据分页、批量删除时，物理外键往往会制造麻烦，而逻辑外键完全够用，性能还更好。这个“不加外键”的做法如果你在答辩时主动讲出来，老师反而会觉得你懂实际开发。
3. 从0到1搭建：实操过程与核心环节实现
3.1 环境准备与项目脚手架生成
开始写代码之前先把环境准备齐：JDK 8或11、Maven 3.6以上、IDEA、MySQL 5.7或8.0、Navicat或DataGrip。
创建项目直接用IDEA的Spring Initializr，或者去start.spring.io生成压缩包。依赖项不用选太多，核心这些就够：
- Spring Web（提供Web能力）
- Thymeleaf（服务端渲染页面，如果你的版本用Vue则不需要）
- MyBatis Framework（数据访问）
- MySQL Driver（数据库驱动）
- Lombok（简化实体类代码，强烈建议加）
- Spring Boot DevTools（开发热部署）
注意：如果打算用MyBatis-Plus，建议自行引入mybatis-plus-boot-starter，而不是用Spring Initializr自带的基础MyBatis依赖，因为版本兼容性自己控制会更稳。版本号建议用3.5.3左右，适配Spring Boot 2.7.x。
3.2 项目工程结构规划
包结构不要乱，按分层架构来，这不仅是代码规范问题，也是论文里软件体系结构设计那一章的现成素材。我建议按这种方式分包：
com.nanjing.food ├── config（配置类：跨域、拦截器、MyBatis） ├── controller（控制层，按业务再拆user/admin） │ ├── user │ └── admin ├── service（业务层） │ ├── impl ├── mapper（数据访问层） ├── entity（实体类） ├── dto（出参入参对象） ├── vo（视图对象） ├── common（统一返回体、异常处理、常量） └── utils（JWT工具、文件上传工具等）这个结构清楚到什么程度呢？答辩时你把IDEA的项目结构截图往PPT里一放，老师基本就懂你的分层思想了。按层分包还有一个实际好处：后面写AOP日志、权限拦截时，切点表达式写起来非常方便。
3.3 统一返回体、全局异常与JWT登录
商城的接口风格最好统一，否则前端判断逻辑会写成一团乱麻。我习惯定义一个Result对象，所有接口返回这个结构：
@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.setCode(code); result.setMessage(message); return result; } }对应的全局异常处理器用RestControllerAdvice实现，业务异常统一抛BizException，把所有SQL异常、空指针之类的底裤错误拦截在内部，返回给前端的永远是结构一致的信息。这个做法在实习和工作中是标配，写进简历的“技术亮点”也不心虚。
登录认证这块，毕设项目用JWT是性价比最高的方案。用户登录成功后用Secret签名生成Token，前端存起来，每次请求带上，拦截器里解析Token并检查用户角色。核心拦截器配置示意如下：
@Configuration public class WebConfig implements WebMvcConfigurer { @Resource private LoginInterceptor loginInterceptor; @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor) .addPathPatterns("/api/**") .excludePathPatterns("/api/user/login", "/api/user/register", "/api/product/list"); } }拦截器做两件事：查Token是否存在且有效；再取用户信息放进ThreadLocal，后续controller里直接拿。注意放行的路径要设计好，比如商品列表、商品详情这些需要登录前就能访问的接口放在白名单里。
3.4 商品模块：从实体到接口的完整链路
商品模块是最标准的CRUD，但要把细节做对。实体类用Lombok简化，字段和数据库对应：
@Data public class Product { private Long id; private Long categoryId; private String name; private String subTitle; private String mainImage; private String detail; private BigDecimal price; private Integer stock; private Integer sales; private Integer status; private Date createTime; }Mapper层用MyBatis-Plus的话，单表查询几乎不用写XML，继承BaseMapper后，靠LambdaQueryWrapper完成条件拼接。比如商品列表按分类筛选：
@Override public List<Product> listByCategory(Long categoryId) { LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Product::getCategoryId, categoryId) .eq(Product::getStatus, 1) .orderByDesc(Product::getSales); return productMapper.selectList(wrapper); }这段代码里的orderByDesc(Product::getSales)是一个很小心机的设计，让列表默认按销量排序，“爆款小吃”的展示效果就出来了。Service层再对新品、热卖、推荐分别做不同条件的查询，Controller层只需要接收参数调用Service。
商品搜索用LIKE模糊查询即可，MySQL的like字段上记得考虑性能，但毕设数据量小，不用过度优化。如果你把搜索词记录到一张hot_word表里，还能在后台做热搜词排行，这个扩展点留给论文也算加分项。
3.5 购物车与下单：事务与库存校验
商城系统真正考验编程功力的地方在下单流程。购物车加商品简单，重点是提交订单的时候必须保证库存不超卖、数据不产生脏数据。
我建议下单逻辑这样设计：第一步，根据用户勾选的购物车记录查出对应的商品列表，逐个检查库存是否充足；第二步，计算出总金额；第三步，生成订单主记录和订单明细记录，同时扣减商品库存，增加商品销量；第四步，清除对应的购物车记录。整个过程必须包在一个事务里，任何一个环节失败都要回滚，否则就会出现“订单生成了但库存没扣”或者反过来“库存扣了但订单没建成”的尴尬数据。
在Service方法上加@Transactional(rollbackFor = Exception.class)即可。说明一下为什么rollbackFor要写Exception.class：Spring默认只在遇到RuntimeException时才回滚，你如果抛的是自定义异常且没有设置rollbackFor，那事务是不会回滚的，这个坑我见过不止一个人踩。
下单时还有一个细节是订单号生成。不要用数据库自增id直接当订单号暴露给用户，太小且可猜测。我用的是时间戳加随机数：
String orderNo = "NJ" + System.currentTimeMillis() + String.format("%04d", new Random().nextInt(10000));前面加“NJ”前缀和南京主题呼应，生成规则简单，答辩时可以顺口说“为了防止订单号被猜测，采用了时间戳加随机序列的方式”，显得有安全意识。
3.6 前端页面整合：模板引擎还是要拆Vue
前端这块有两条路。如果你时间紧，想快速跑通整体效果，用Thymeleaf做服务端渲染就够，Controller返回ModelAndView，页面里用th:each遍历商品列表，代码少，部署简单，直接打成一个jar包丢服务器就能跑。Layui、Bootstrap这类后端友好型前端框架配合使用，页面效果不会太差。
如果你已经学过Vue，而且想做前后端分离，体验更接近真实企业开发，前端单独起一个Vue项目，打包后将dist目录里的静态文件复制到Spring Boot的src/main/resources/static下，后端再加一个跨域配置类。前端打包后放进Spring Boot里运行是一个很常规的做法，这样部署时仍然只需要一个Spring Boot进程，老师演示的时候不用额外启动npm服务。跨域设置核心是这样：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*") .allowCredentials(true); } }两条路怎么选？我的建议是：如果你Java基础一般，想稳稳过毕设，选Thymeleaf；如果你想在简历里写“熟悉前后端分离开发”，选Vue。前者省时间，后者涨经验。但无论选哪种，后端接口设计都要清晰，这比页面本身重要得多。
3.7 种子数据：把南京美食“写”进系统
第一次启动项目后，系统里如果空空如也，演示效果会很干。我强烈建议准备一份SQL种子数据，预置用户、管理员、分类和商品。商品数据要从大众点评、美团这些生活服务网站找灵感，自己组合成合法的示例数据：
- 分类“秦淮经典”：鸭血粉丝汤、桂花糖芋苗、赤豆酒酿小元宵
- 分类“金陵卤味”：盐水鸭、酱鸭头、鸭四件
- 分类“风味小吃”：牛肉锅贴、鸡汁汤包、皮肚面
- 分类“传统糕点”：绿豆糕、云片糕、状元豆
每个商品的描述字段可以写一小段美食介绍，比如“鸭血粉丝汤由鸭血、鸭肠、鸭肝、粉丝制成，汤头鲜美，粉丝爽滑”，这会让后台和前端页面看起来丰满得多，也是论文截图的素材。图片可以从开放图库或爬取一些有授权的示例图，注意项目内使用不要涉及版权纠纷，本地演示用没有太大问题。
4. 避坑指南：常见问题与排查技巧
4.1 Spring Boot版本“太新”引发的连锁问题
好多人一开始图新鲜用了Spring Boot 3.x，结果碰到的第一个问题是javax包全部变成了jakarta，老的教程代码复制过来直接编译报错。然后是MyBatis-Plus的starter版本跟不上，动态数据源等一堆功能失效；再想降级回2.x，又因为IDEA缓存问题折腾半天。
我的建议非常简单直接：毕设项目老老实实用Spring Boot 2.7.x。不是因为3.x不好，而是你的目的是顺利毕业、吃透原理，没必要在兼容性上给自己增加情绪成本。如果你用了2.7.x还碰到某些starter版本问题，统一去Maven仓库查该starter对Spring Boot 2.x的对应版本号，宁可用稳定版、不加新功能。
4.2 端口占用与配置不生效
Spring Boot启动时报“Port 8080 was already in use”是很常见的。解决办法要么换个端口，在application.yml里修改：
server: port: 8081要么杀掉占用进程。Windows下用netstat -ano | findstr 8080查PID，然后taskkill /pid PID /f。如果改了端口还是不生效，检查是不是有多个application文件，Spring Boot的配置文件加载优先级是application.yml优先于application.properties，同时存在的时候哪个生效容易记混，建议只保留一种格式。
4.3 Maven依赖冲突与下载慢
Maven依赖冲突的典型场景是引入了多个版本的某个库，导致运行期NoSuchMethodError。出现这类问题，先在IDEA的Maven面板点一下“Show Dependencies”，查看依赖树，再用exclusion排除冲突项。国内Maven仓库下载慢，建议在settings.xml里配置阿里云镜像，这个配置一次，整个项目期间都舒服。
4.4 前后端联调中的跨域问题
前后端分离时，前端启动在localhost:5173，后端跑在8080，接口请求被CORS拦截，这是出现频率最高的联调问题。控制台报错会告诉你“CORS policy”。解决办法已经在上文代码里给出，注意allowCredentials(true)和allowedOriginPatterns("")要配合使用，如果单独用allowedOrigins("")在带Cookie请求时会报错。
还有一种情况是后端配置了跨域但前端还是不通，那就要检查是不是经过网关或nginx转发导致Host头变化。本地联调一般没有这层，但如果发现配置没问题仍然报错，打开浏览器F12看请求响应头里有没有Access-Control-Allow-Origin字段，有就说明后端配置生效，问题出在前端。
4.5 中文乱码与文件上传
中文乱码的原因分两个层面。数据库层面，建库时字符集设置为utf8mb4，连接串里写上characterEncoding=utf8，这两个都做到一般不会乱。页面层面，如果是Thymeleaf，在页面head里加meta charset="utf-8"，Controller返回字符串时注意ResponseBody的编码。文件的乱码常见于Excel导出，但毕设项目一般接触不到，先把数据库和页面的稳住就行。
图片上传是商城必备功能。本地上传时，注意在配置里指定一个绝对路径作为上传目录，然后通过自定义映射暴露为静态资源：
@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath + "/"); }这个配置经常被忽略，导致图片上传成功但前端图片显示不出来。另外上传时限制文件类型和大小，防止有人上传恶意文件，拦截器里加一层校验会比较稳妥。
4.6 对应高频面试题的自我复盘
做完项目后，花半天把Spring Boot的一些高频面试题自己过一遍，答辩和面试都用得上。比如：Spring Boot的核心注解@SpringBootApplication是由哪几个注解组合来的；自动配置原理是什么，如何自定义starter；“Spring Boot版本太高”在简历上不能直接写，应该说“熟悉Spring Boot的版本兼容处理与依赖管理”。订单超时未支付怎么取消、库存防超卖怎么做，这种场景题也可以把项目里的实际方案整理成腹稿，面试官一听就知道你是真做过还是只看过教程。
5. 论文写作与答辩准备
5.1 论文结构怎么排
这篇论文的核心骨架，大部分学校都接受这种结构：
第一章 绪论，写研究背景（南京旅游餐饮现状）、国内外电商系统发展现状、研究意义和主要内容。南京特色在这里可以好好写，但别写太满，两到三页足够。
第二章 相关技术介绍，把Spring Boot、MyBatis、MySQL、JWT、Thymeleaf或Vue介绍一遍。注意不能只是名词解释，最好每项技术都写一句“为什么选它”，比如“JWT无状态认证机制适合前后端分离下的会话保持”。
第三章 系统分析，写可行性分析（技术、经济、操作）、需求分析（用户端功能需求、管理端功能需求）、用例图。功能列表直接对照本文第二部分的内容，画用例图时角色就两个：普通用户和管理员。
第四章 系统设计，写总体架构图（表现层、业务层、数据层）、功能模块设计、数据库设计。数据库部分把本文的每个表结构整理成表格或ER图，这一章是字数主力。
第五章 系统实现，按功能模块逐个写实现思路、贴核心代码、放页面截图。图文结合，每小节都要有截图，这是老师最看重的部分，页面截图至少准备15张以上。
第六章 系统测试，写测试环境、测试用例表格、测试结果。不需要复杂的自动化测试，把每个功能模块的测试用例、输入、预期结果、实际结果写清楚，强调“系统功能完整，响应时间满足预期”。
5.2 如何把“工作量”写实
很多同学论文写得薄，是因为从头到尾只写了“做了什么功能”，没有写“怎么做的”。把细节铺开，比如：库存扣减你用了事务控制，那就在论文里写一段“并发下单场景下可能出现超卖问题，本系统通过@Transactional事务管理保证数据一致性”；密码加密用了BCrypt，写一句“为保证用户信息安全，密码不采用明文存储，而是使用BCrypt加盐哈希”。
另外可以适当加入一些不算复杂但体现思考的设计：订单号规则设计、Redis缓存热点数据（如果你用了）、AOP日志记录。这些点不用多，一两个即可，但一定要能讲清原理，不然老师追问你会露出破绽。
5.3 答辩现场的高频提问与应答思路
答辩老师问的问题往往不深，但一定会围绕你的项目真实性进行验证。高频问题如下：
“你这个系统的订单流程是怎样的？”把待付款、待发货、待收货、已完成、已取消五个状态，以及每个状态对应哪些操作背熟，流畅说出来就过关。
“数据库为什么这样设计？”从三条线回答：商城核心是商品、订单、用户三个实体；订单和商品是多对多，所以引入了订单明细表；商品与分类是一对多，分类与商品构成树形关系。这样回答逻辑清楚，老师挑不出毛病。
“首页销量排行是怎么实现的？”记得是你商品查询接口里加了orderByDesc(sales)，顺带说明每次下单成功会增加sales字段。这是一个很容易回答但也很容易忘的细节，提前想好。
“系统遇到过什么Bug？”哪怕是“上传中文名图片后访问404”这种小问题都可以讲，关键要说出你的排查思路和解决过程，这种回答最能证明项目是亲自动手做的。
写在最后的一点经验
我自己带过的同学里，凡是顺利通过答辩的，几乎都有一个共同点：他们对系统的业务逻辑了然于心，哪怕遇到没见过的追问，也能从模块职责、数据流的角度推出来。做这个南京美食商城项目，编码本身大概一到两周能全部跑通，但值得多花时间的反而是把每一个设计细节想明白，比如为什么订单明细要冗余商品快照、为什么购物车存数据库而不存浏览器、为什么管理员和用户的接口要分开鉴权，这些才是论文和面试真正会考察的东西。
最后分享一个小技巧：项目跑通之后，把系统里预置的商品补齐一些有南京特色的文案和图片。答辩演示时，你点开“盐水鸭”详情页，屏幕上是一段干净又生动的介绍，评委大概率会顺着问一句“这些数据是你自己录入的？”你回答“是的，同时设计了初始数据脚本”，这个细节会让整个系统的完成度立刻上一个台阶。
