每年到了毕设季总有人在群里问“有没有简单好做的管理系统”但真正拿到这类销售系统题目的人又觉得太普通、不知道怎么写才能过。其实像“基于Spring Boot的甘肃特产销售系统”这种题恰恰是毕设里性价比最高的一类技术栈主流、业务闭环完整、演示效果好而且非常容易讲清楚。这篇文章我就拿这个具体的项目做例子把需求拆分、数据库设计、核心代码、启动步骤、答辩防问全都过一遍目标只有一个——让你拿到源码之后能真正讲明白、跑得起来、答得上老师的追问。1. 甘肃特产销售这个题目到底在考察什么核心能力1.1 特产电商的业务痛点和题目价值甘肃特产的电商销售本身就是一个特别适合做成毕设的业务场景。甘肃的兰州百合、苦水玫瑰、临夏牛羊肉、定西土豆、天水花牛苹果、陇南橄榄油、武都花椒等等单品知名度不低但产地分散、中小商户多一直没有特别集中的线上销售渠道。系统如果能把“特产展示—用户下单—后台发货”串成完整的闭环就已经覆盖了电商类项目最核心的主线。很多同学担心“销售系统是不是太老套了”我的观点是毕设的重点不在题目新旧而在于功能是否闭环、技术是否有足够的复杂度。一个订单状态机、一个库存并发扣减、一个权限控制、一套可复用的分页查询这四个硬骨头啃下来比做十个花哨页面更有说服力。老师的评分点也往往集中在这几个地方需求是否合理、表设计是否规范、事务有没有控制好、权限有没有漏洞。1.2 用户端和管理端的功能版图这个系统的功能可以分成两条线一条是面向消费者的用户端一条是面向运营者的管理端。用户端的核心路径是注册登录 → 浏览分类/搜索商品 → 查看详情 → 加入购物车 → 提交订单 → 模拟支付 → 查看订单状态管理端的核心路径是管理员登录 → 商品分类管理 → 商品上下架与库存调整 → 订单审核发货 → 用户与数据统计。有些同学会把用户端做得很重页面花里胡哨但后台功能草草带过。我建议反过来后台管理才是答辩时最能体现项目完整度的地方。因为老师通常只会看到你搭好的演示环境你在前台点几下购物车、下单最多花两分钟剩下的时间基本都在聊后台的订单处理、商品排期、统计图表这些“看不见的部分”。1.3 隐藏的加分项非功能需求功能列表之外非功能性东西往往才是拉开档次的地方。比如密码不能明文存储、接口返回格式要统一、页面不能直接访问后台静态资源、错误提示要友好而不是满屏异常栈。这些听起来很基础但相当一部分毕设演示现场就是这么翻车的密码输错了直接白屏、刷新一下购物车数据全丢、把管理员的id改成别人的id就能看到别人的订单。所以在设计时我会额外做几件事统一返回结果类、全局异常处理器、登录校验拦截器、SQL注入与XSS的基础防护。这些在答辩里挑出来讲老师会明显感觉到你不是在“照着抄代码”而是真的在思考一个线上项目该有的样子。2. 技术选型为什么是这套组合拳2.1 毕设技术栈的横向对比我用一张表说说常见方案的取舍方便你在改题目时也心里有数。方案前端方式适用场景主要缺点SSM JSPJSP Bootstrap老课设延续老师指定前后端不分离配置繁琐Spring Boot Thymeleaf服务端模板渲染快速出效果、演示稳定动态交互弱适合管理端重Spring Boot Vue前后端分离商城类前台体验好需要额外部署前端联调成本高微服务拆分不限冲高复杂度撑不起业务量容易被追问甘肃特产销售系统我建议用Spring Boot Vue或Thymeleaf的常规搭配具体看你的前端基础。如果前端一般Thymeleaf加Bootstrap足够应付服务端渲染对SEO友好演示时也不用开两个服务如果前端有点底子Vue做前后端分离会让购物车、商品列表的交互顺畅很多代码结构也更像真实项目。重要的是不要在毕设阶段引入微服务、分布式事务这类复杂度业务量撑不住老师还会连环追问你“为什么这里不用消息队列”答不上来非常尴尬。2.2 Spring Boot版本与核心依赖清单版本方面如果用的是Spring Boot 2.7.x搭配JDK 8或11最稳妥相关依赖的兼容性问题最少想紧跟新一点的可以选择Spring Boot 3.x搭配JDK 17但要注意部分老教程中的javax包需要改成jakarta很多同学在这里踩坑。防护性和社区资料量综合考虑我建议毕设优先2.7.x理由很简单你搜到的大部分中文资料、开源项目在这个版本上都验证过。核心依赖大致是这样spring-boot-starter-webWeb服务和REST接口spring-boot-starter-validation参数校验spring-boot-starter-data-redis购物车/缓存可选mybatis-plus-boot-starter持久层增强CRUD和分页非常省事mysql-connector-java数据库驱动spring-boot-starter-security / 或自己写拦截器JWT登录认证lombok简化实体代码knife4j / springdoc-openapi接口文档我在做这个项目时倾向用MyBatis-Plus而不是纯MyBatis或Spring Data JPA。原因是MyBatis-Plus在毕设场景下确实“开箱即用”内置单表CRUD、分页插件、条件构造器能帮你省掉大量重复的XML写法和DAO代码但要注意不要什么查询都用框架自带方法涉及多表联查的订单明细、统计报表还是要手写SQL这样答辩被问到“底层怎么执行”时才不会答不上来。2.3 工程结构设计和数据库骨架包结构可以参考经典的按模块分包方式com.gansu.tesale ├── common │ ├── Result.java │ ├── ResultCode.java │ └── GlobalExceptionHandler.java ├── config │ ├── WebMvcConfig.java │ ├── JwtInterceptor.java │ └── MybatisPlusConfig.java ├── controller │ ├── admin │ └── front ├── entity ├── mapper ├── service │ └── impl ├── dto ├── vo └── utils实体、Mapper、Service、Controller的经典分层容易讲清楚Controller只管参数接收和结果返回Service里放业务逻辑Mapper负责和数据库打交道。这里要特别强调一点业务逻辑不要堆在Controller里答辩时老师会翻代码看到Controller几百行一定会扣印象分。数据库方面核心表包括用户表user、分类表category、商品表product、购物车表cart、订单表orders、订单明细表order_item、收货地址表address也可以加上公告表notice。表结构不必追求多么高大上但外键逻辑、状态字段、时间字段要完整。订单和订单明细建议用订单号关联而不是外键因为查询统计时业务更灵活。3. 六个核心模块的代码级拆解3.1 商品检索与分类联动用户进到首页后第一眼看到的就是商品列表所以商品检索体验很重要。我的实现思路是分类筛选 关键字模糊搜索 价格区间 排序条件这些条件组合在Service层里通过LambdaQueryWrapper完成。如果是MyBatis-Plus可以直接这么写LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(Product::getStatus, 1); // 只查询上架商品 if (StringUtils.hasText(categoryId)) { wrapper.eq(Product::getCategoryId, categoryId); } if (StringUtils.hasText(keyword)) { wrapper.like(Product::getName, keyword); } wrapper.orderByDesc(Product::getSales); PageProduct page productMapper.selectPage(new Page(pageNum, pageSize), wrapper);为什么强调加status条件因为后台下架的商品绝不能出现在前台列表里这是一个非常容易漏但必须有的业务约束。很多同学直接在Mapper里写“select * from product”演示的时候后台把商品下架了前台还能搜到这就是逻辑上的一个硬伤。另外商品列表返回给前端的VO里不要把描述类的长文本整个返回列表页只给封面图、标题、价格、销量详情页再单独查完整信息能明显减少不必要的MySQL查询压力。3.2 购物车的两种实现路径购物车环节有人用Redis有人用数据库表也有人直接存Cookie。我的实现建议是分场景如果你为了展示会一点Redis把购物车数据存RedisKey设计成cart:userIdValue用JSON保存商品项列表好处是响应快、代码看起来“高级”但要注意Redis宕机后购物车数据会丢所以订单生成时仍然要从商品表重新核对价格和库存如果不用Redis那就老老实实用cart表存user_id product_id做唯一索引每次加购走一次upsert。从毕设稳妥性出发我建议数据库存购物车。理由很简单演示环境不稳定Redis服务没起或者密码配置错页面直接报错老师等着看你演示呢没必要在这上面冒险。购物车表建议字段包括id、user_id、product_id、quantity、checked、create_time加购接口幂等性处理就是如果当前用户已添加过该商品就更新数量而不是重新插入记录避免购物车越来越长。3.3 订单状态机与事务控制订单是整个系统里最容易讲出深度的模块。我的状态字段一般定义成0待支付、1已支付待发货、2已发货待收货、3已完成、4已取消。下单接口里做的是这些事校验用户是否登录、校验商品是否上架、计算总金额、扣减库存、生成订单主表和明细表、清空购物车相关项。这五步必须在一个事务里完成否则就会出现“订单生成了但库存没扣”这种前后台对不上的情况。Spring Boot里最简单的做法是在Service方法上直接加Transactional。这一步是答辩的基础分一定要能说清楚为什么需要事务因为要么全部成功要么全部回滚。如果你用了模拟支付支付成功回调里也要把订单状态、支付流水写入同一个事务防止回调重复调用导致金额状态紊乱。建议在下单时生成一个业务订单号比如时间戳用户id随机数订单号不要用自增id因为对外展示的订单号一旦暴露别人可以遍历看到所有订单会带来越权风险。3.4 库存扣减的并发处理库存并发是销售系统的经典考点。多数毕设会写成“先查询库存再减库存”这在单用户演示时没问题但老师如果问“如果100个人同时买最后一件商品怎么办”你就需要给出方案。我这里用的方案是乐观锁式的SQL扣减UPDATE product SET stock stock - #{quantity}, sales sales #{quantity} WHERE id #{productId} AND stock #{quantity}执行这条SQL后如果影响行数为0说明库存不足或者商品状态已经变化直接抛出业务异常提示“库存不足”。这是一条原子操作不用先查再改天然防止了超卖。还可以在商品表加一个version字段做乐观锁不过对于毕设来说where条件里带stock quantity这种“条件更新”已经足够讲起来也好理解。这里要提醒一个细节扣减库存和更新销量是在同一个SQL里完成的。很多同学只减库存不更新销量结果首页按销量排序时永远一个样子功能不完整。销量字段对“特产推荐”这类场景很重要是商城运营概念里非常直观的体现。3.5 模拟支付的设计毕设里接真实支付渠道基本不现实需要营业执照、商户号审核周期也长。所以行业内通用的做法是模拟支付。我做的支付模块是两步第一步是下单后生成支付单返回支付页第二步是前端调用“模拟支付成功”接口后端把订单状态从待支付改成已支付同时插入一条支付流水记录支付方式、支付金额、支付时间。模拟支付的好处是演示链路完整又不至于被卡在资质申请上。答辩时你要主动说明真实环境只需替换支付回调的验签逻辑业务代码不用大改。这句话很加分说明你理解支付系统的扩展点在哪里。另外订单超时未支付自动取消这个功能如果时间充裕可以加一个定时任务比如Spring自带的Scheduled每30秒扫描一次超过30分钟未支付的订单将状态置为已取消并回补库存。这个功能虽然简单但覆盖了“订单生命周期管理”的完整度。3.6 登录与权限拦截器前端可能暴露给游客的接口只有查询类的凡是涉及购物车、订单、地址、个人中心都必须校验登录状态。我用JWT做登录令牌用户登录成功后后端生成token返回前端把它存在localStorage里每次请求放在Authorization请求头后端有一个拦截器统一拦截需要登录的路径从token里解析出userId放入请求上下文。管理端的拦截更严格。可以给用户表加一个role字段1是管理员、0是普通用户再设置一个检查当前用户role是否等于1的判断不是就直接返回403。这样用户不可能通过改页面上的按钮进入后台因为后台接口路径和普通接口路径分开普通token即使携带了也无法通过管理端的鉴权。密码存储必须用BCryptPasswordEncoder加密不要用MD5。MD5不加盐在现在看就是笑话老师问到安全问题这个点必须答得滴水不漏。4. 从空项目到跑通演示复现步骤与联调记录4.1 环境准备和版本搭配拿到源码后第一步是核对环境版本避免在启动阶段浪费时间。推荐版本组合为JDK 8或11、Maven 3.8、MySQL 5.7或8.0、Spring Boot 2.7.x。如果你的机器上同时装了多个JDK版本注意在IDEA的Project Structure里把Project SDK和模块的SDK指向同一个版本否则会报“无效的源发行版”这类奇怪错误。IDEA里导入项目时选Import Maven Project让Maven把依赖完整拉下来这个过程受网络影响可能很慢不建议断网等待太久可以先配置阿里云镜像。MySQL安装后需要手动创建一个数据库比如命名为gan_su_shop字符集选utf8mb4。为什么强调utf8mb4而不是utf8因为特产名称和用户收货地址里完全可能包含特殊字符和生僻字utf8mb4对emoji和扩展字符支持更好订单地址里有特殊符号也不会入库报错。4.2 初始化项目与配置数据库SQL脚本一般会放在sql目录下包含建表脚本和初始数据脚本。执行完脚本后修改application.yml里数据库连接信息即可启动spring: datasource: url: jdbc:mysql://localhost:3306/gan_su_shop?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl mapper-locations: classpath*:mapper/**/*.xml有两个地方经常出问题。第一个是serverTimezone不配置或者配成UTC查询时间经常会差8个小时第二个是密码里如果带有特殊字符比如#、在yaml里需要加引号包裹不然会被解析成注释或特殊符号导致连不上数据库。日志配置可以先用StdOutImpl打印SQL方便对照参数排查问题但演示前最好关掉避免控制台刷一堆SQL影响展示观感。4.3 初始数据的填充技巧SQL脚本里除了表结构还应该有一段INSERT INTO的初始数据涵盖管理员账号、测试用户、商品分类、上架商品、订单示例。商品图片建议使用本地静态资源或者图床链接不推荐在代码里硬编码成绝对路径。如果你用本地上传要配置一个虚拟路径映射让上传的图片能通过URL访问例如Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath file: System.getProperty(user.dir) /upload/; registry.addResourceHandler(/upload/**).addResourceLocations(uploadPath); }商品测试数据尽量真实一点比如“兰州真空鲜百合”价格、规格、产地都写清楚老师浏览的时候会觉得你认真做了业务调研。初始管理员账号一般建议是admin/123456测试用户是user/123456演示前最好先把密码改成你觉得顺手的组合但记得源数据里也要同步修改避免演示现场忘记密码。4.4 前后端联调的接口约定前端页面和后端接口的联调最怕的就是字段名对不上。我建议一开始就约定统一响应格式为{code: 200, message: success, data: {...}}前端拿到code为200才渲染数据否则弹错误提示。后端接口路径统一前缀比如用户端接口都用/api/front/**管理端用/api/admin/**这样拦截器好配置前端也清楚哪些需要带token。如果你自己做Vue页面推荐用一个axios封装统一处理请求头// request.js const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config })前端联调常见的报错有两个一是跨域开发环境可以用Vue的proxy代理把所有/api请求转发到后端localhost:8080这样最省事二是404检查一下你Controller里的RequestMapping路径和前端调用的路径是否完全一致包括大小写和末尾斜杠。联调阶段最好打开浏览器开发者工具看Network面板里请求的状态码和后端返回的具体内容比盲猜快得多。5. 答辩撑场与避坑实录5.1 答辩高频问题答辩老师问来问去就那么几类提前准备好就够了。第一类是关于技术选型比如“Spring Boot和传统SSM有什么区别”可以从自动配置、内嵌服务器、生态整合三个角度回答第二类是关于数据设计和事务比如“下单时如果库存不够怎么办”“一个用户同时买两个商品订单表怎么存”注意答出主表和明细表的设计思路第三类是关于安全性比如“密码是怎么存储的”“能不能直接访问后台接口”把BCrypt和JWT拦截器方案讲清楚即可。还有一个高频追问是“这个项目里有哪些地方是你自己实现的哪些是调包调API的”我的建议是诚实地区分同时突出自己动脑的部分。比如商品列表的条件分页查询、订单超时取消的定时任务、模拟支付回调的设计这几个点都属于“业务逻辑层”的思考比单纯说“用了MyBatis-Plus”要有含金量。回答时不要背概念尽量结合代码里实际的类名和接口名讲老师会顺着问你真实写过就能答上来。5.2 我实际踩过的坑和排查过程第一个坑是JSON序列化循环引用。商品和分类如果建立了双向关联关系直接用List返回给前端时会出现无限递归启动时可能没报错一调用接口就出现StackOverflow。排查方法是打开控制台看异常栈定位到Category和Product的互相引用后在实体类的一个方向上加JsonIgnore或者在VO层做转换。第二个坑是MyBatis-Plus的分页不生效。很多人配置了PaginationInnerInterceptor但没有把拦截器注册到MyBatis-Plus的配置里结果Page查询本来应该返回2条却返回全部数据。检查你的MybatisPlusConfig确认Configuration标注了并且MybatisPlusInterceptor里添加了分页插件。第三个坑是上传图片后刷新页面图片没了。原因是IDEA里重启项目会把工作目录下的upload临时文件清掉尤其是target目录下的部署包。所以要么把上传路径配置成固定的磁盘目录比如D:/upload要么把样例图片直接放在代码资源目录里而不是运行期再上传。第四个坑是和Session有关的。有些同学会用Session存登录状态但Thymeleaf页面和前后端分离接口混在一起用一会从Session取userId一会从token里取逻辑非常混乱。后来我统一改成JWT把用户信息从token里解析所有接口都从通用方法里获取当前登录用户问题就消失了。这一点要提醒代码里不要有多套登录状态机制并存那一定会在某个演示环节出妖。5.3 这个项目的扩展方向如果时间和精力允许有几个扩展方向可以提到答辩的最后加分阶段。第一个是数据可视化管理端首页增加统计图表比如每日订单量、销量Top商品、分类销售占比后端用SQL按日期或分类聚合前端用ECharts画图。第二个是增加推荐逻辑比如按用户历史购买记录推荐同类特产不用复杂算法一条关联查询加权重排序就能实现。第三个是接入MinIO或阿里云OSS做文件存储把本地图片上传换成对象存储可以顺便聊一聊分布式系统中静态资源沉淀的常识。还有一点如果你是“毕设分享”中的一员要谨防直接把别人的源码原封不动交上去。哪怕只是改几个功能模块、把页面文案换成新的特产品类、增加一个收藏功能也能让项目“长”在你自己的脑子里面。老师看过的毕设太多了你讲项目时的底气到底足不足一眼就能看出来。真正把代码跑一遍、改过一个bug、重命名几个实体类之后你再面对答辩就不会慌。我在实际带这类项目时最深的一个体会是销售系统看起来无非是增删改查但它是最能体现“工程思维”的课设类型之一。业务紧凑、环节多、容易讲深也最容易让老师觉得“这个人真的会写代码”。只要你在事务、库存、权限和支付这几个关键节点上多想一想“为什么”而不是把所有Controller写成一坨“万能增删改查”这个毕设的含金量就已经超过大多数人了。最后给你一个小建议拿到源码后先别急着改功能照着数据库脚本把每个表的外键关系画一遍再顺着前端页面把一个订单完整的走一遍做完这两步你就有资格说这个项目是你自己的了。