1. 项目定位与需求分析1.1 为什么无人机销售系统是个适合做毕设的题目每年毕业季总有人抱着技术栈清单挑题目Spring Boot 配电商业务是整个 Java 生态里最稳妥的组合之一。而这次要拆解的“基于 Spring Boot 的无人机销售系统”并不是一个流于形式的 CRUD 拼装项目。它的业务逻辑天然包含了商品管理、购物车、订单流转、用户权限、支付回调、售后处理多个环节每个环节都对应一套明确的技术点非常适合用来展示毕设的“完整度”。很多同学在挑毕设题目时容易踩两个坑。第一个坑是题目过窄比如“图书管理系统”核心逻辑只有增删改查论文和答辩都撑不起深度第二个坑是题目过宽比如“大型电商平台”对于一个人的毕设来说根本做不完最后只能拿半成品糊弄答辩时一问细节就露馅。无人机销售系统刚好卡在中间——它足够接近真实商业系统但需求边界又能控制在一个完整可交付的范围内。既能写清楚业务分析和系统设计又能在源码里体现模块拆分和异常处理这正好符合结业项目评委想看到的东西。所谓的“无人机销售系统”一般包含三类使用角色。普通游客可以浏览商品、查看详情注册成用户后能管理收货地址、下单、查看订单物流状态店铺运营人员负责商品的上架下架、库存维护、订单发货和售后处理系统管理员负责用户管理、数据统计和基础配置。三套视角叠加在一起就构成了这个系统的完整权限边界和业务闭环。1.2 认可这个项目的人需要提前明白三件事如果你决定参考或者复现这个项目我先给你打三针“预防针”。第一Spring Boot 只是框架它不帮你写业务。很多人看到“基于 Spring Boot”就以为项目自动就高级了实际上 Spring Boot 解决的是开发效率问题真正让你在答辩中站得住脚的是订单状态机的设计、并发库存扣减的逻辑、用户权限的拦截这些细节。第二无人机只是一个业务载体。这个系统的核心其实是“销售系统通用能力”你把无人机换成手机、手办、数码配件代码层面的改动非常小。面试官和评委真正关心的不是你卖什么而是你如何处理电商场景下的通用问题。第三源码你能拿到但“能跑”和“懂它”之间隔着很大距离。调试运行能力比代码本身值钱这也是这类项目附带讲解服务的价值所在。我会在后面的章节里把从搭建环境到调通接口的完整路径拆给你看。2. 技术选型与项目整体设计2.1 后端技术栈选型与版本选择的思考技术选型不是越新越好而是要匹配毕业设计的“可解释性”和“稳定复现性”。最优先考虑的是 Spring Boot 2.7.x 系列不是因为它最新而是因为它大概率能兼容你现在电脑上已有的 JDK 8 环境。虽然 Spring Boot 3.x 是发展方向但 JDK 17 和 Jakarta EE 命名空间的变化容易带来额外的兼容性问题而这些兼容性问题会严重消耗你的调试时间。配套的持久层框架实用主义推荐 MyBatis-Plus而不是传统 MyBatis。这两个框架之间没有任何冲突但 MyBatis-Plus 提供的 BaseMapper 能省掉大量重复的 XML 映射代码把精力用在业务封装上。对做毕设而言这属于必要的“时间诚实地花在刀刃上”。数据库选 MySQL 5.7 或 8.0 都行。如果已经装了 8.0就继续用 8.0如果本地还没有 MySQL建议直接装 8.0字符集设置 utf8mb4避免无人机详情页里出现 Emoji 表情符号时乱码。Redis 在这个系统里承担两部分工作一是缓存无人机热门商品的详情数据降低数据库压力二是存放购物车数据和用户登录 token。缓存逻辑写到“可选加分项”里有时间就加上论文里能多写一章缓存设计。认证授权的实现很多教学项目还在用 Session但这套系统的多端结构决定了用 JWT 更合理。用户端和后台管理端共用同一套用户体系时JWT 无状态认证天生适合前后端分离的交互模式。token 过期时间设置成 24 小时订单模块里对 token 有效期的检测就是一个非常自然的权限演示场景。2.2 前端方案与前后端分离的交互逻辑前端方案不强制要求你会大前端但这套系统要做得“有模有样”至少需要 Vue 2 Element UI 或者 Vue 3 Element Plus 二选一。如果你对前端只是“短平快能跑”的水平选 Vue 2 生态更成熟踩坑的社区答案也更多。如果还想兼顾移动端的演示效果可以在生产构建之后加一个简单的移动端适配。前后端通过 RESTful API 交互接口统一前缀/api。比如查询无人机列表是GET /api/product/list下单操作是POST /api/order/create支付回调模拟是POST /api/pay/notify。前端的 axios 实例统一封装了 token 注入、状态码拦截和错误提示后端通过拦截器验证 JWT。这一整套交互设计展开讲就是论文里的“接口设计和系统通信设计”章节。在项目目录上后端遵循标准分包结构前端是标准的 Vue 工程结构。后端项目的代码放在一个仓库里前端代码放在另一个子目录或独立仓库启动时分别运行。开发环境的跨域问题通过 Vue 的 devServer 代理解决生产环境则把后端接口统一归置到同一个域名下避免 CORS 策略带来额外麻烦。2.3 项目目录结构与每个包的职责后端源码的包结构我建议按业务模块分包而不是按技术层分包。业务分包对答辩时的逻辑讲述非常友好。预览一下核心目录com.drone.sale ├── common # 通用模块 │ ├── config # 跨域配置、拦截器配置、Redis配置 │ ├── exception # 全局异常处理器 │ ├── result # 统一返回对象 ResultT │ └── utils # 订单号生成工具、JWT工具、日期工具 ├── controller # 接口层用户端、管理端分目录 ├── service # 业务层含接口和实现类 ├── mapper # MyBatis-Plus 数据访问接口 ├── entity # 数据库实体类 └── drone ├── product # 商品模块 ├── order # 订单模块 ├── cart # 购物车模块 ├── user # 用户模块 └── admin # 后台管理模块controller、service、mapper 这三层之间的调用规则一定是单向的不允许 controller 直接调 mapper。这是答辩老师看了源码之后大概率会验证的代码规范。业务异常要抛自定义异常而不是返回 null 或者裸返回 Map。全局异常处理器统一捕获业务异常和未知异常返回统一的 JSON 结构前端拿到错误码后做统一提示。这些细节写在论文的“系统详细设计”里都是实打实的打分点。3. 核心功能模块实现细节3.1 商品管理与分类模块的完整链路无人机商品模块是整个销售系统的基础核心数据模型是“商品 SPU 规格 SKU”。简单解释一下这两个概念SPUStandard Product Unit是“标准化产品单元”相当于“大疆御系列某个型号”SKUStock Keeping Unit是“库存量单位”指的是具体规格比如“某型号标准版”“套装版带备用电池”。一般用户在浏览页面看到的是 SPU 列表点进详情页后选择具体规格对应到 SKU 的价格和库存。商品列表页支持按分类筛选、按品牌筛选、按价格区间筛选还支持分页和模糊搜索。这个模块用 MyBatis-Plus 的 LambdaQueryWrapper 再配合 Page 对象写起来并不复杂但有几处关键逻辑不能省。一是商品上下架状态要和库存联动库存为 0 的商品要自动改为“下架”状态避免用户下单之后等不到货。二是商品详情页的“浏览量累计”要考虑缓存不能每次刷新都打到数据库。商品图片的处理规范也应该作为一个亮点写进论文。无人机商品的图片通常不超过 5 张存放在本地磁盘或者云存储中数据库只存 URL 路径。项目里我建议把图片放在一个独立的upload目录下通过WebMvcConfigurer配置静态资源映射这样上传和访问两种能力就都具备了。3.2 购物车模块Redis 集中管理与合并逻辑购物车模块有两套实现思路。第一套是传统数据库持久化方案用一张 cart 表存储用户与商品的对应关系优点是逻辑简单、断电不丢数据缺点是频繁读写下数据库压力大而且对“游客购物车”的支持很尴尬。第二套方案是 Redis 以用户 id 为 key存储商品 id 和数量映射的 Hash 结构优点是读写快、天然支持过期时间缺点是如果用户没登录Redis 里那一份数据怎么处理就成了设计问题。这套系统选的是“未登录存浏览器 localStorage登录后合并到 Redis”的方案。用户在未登录状态下把商品加入购物车数据存到前端 localStorage 里当用户点击登录或者下单时前端先把 localStorage 中的购物车清单传回后端后端以 Redis 里的数据为基础逐条合并相同商品的数量然后把合并结果写回 Redis。这个合并逻辑在论文和答辩里是一个值得展开的亮点它体现了你对实际电商业务的理解。购物车数据处理有一个容易漏的边界情况Redis 中的商品数据可能在后台被运营人员下架了。用户打开购物车页面时后端要批量查询商品状态把已下架或已删除的商品从购物车中剔除并向前端返回明确的“商品已失效”标记。这些细节说明白答辩时就能体现出系统的严谨度。3.3 订单与支付模块的状态机设计订单模块是整个系统的压轴模块也是最容易在答辩中被深挖的部分。订单状态不能只用一个字符串字段随便存应该用状态机来约束状态的流转路径。我为这个系统设计的状态包括待支付、已支付待发货、已发货、已签收、已完成、已取消、退款中、已退款共 8 个状态。状态之间的合法流转路径必须是单向且明确的。待支付可以取消也可以支付成已支付待发货已支付待发货可以发货成已发货也可以主动申请退款已发货可以签收成已签收也可以走售后发起退款已签收之后只能走售后流程已退款是终态。所有不满足状态流转规则的操作后端都要做拦截并抛出对应的业务异常。这个设计在代码层面用OrderStatusEnum和状态机判断类实现在论文里对应的章节就是“订单状态机设计”。支付模块虽然是模拟支付但逻辑不能做得太儿戏。我建议对接沙箱支付接口或者实现一个模拟的银行支付接口用户点击支付时系统创建一条支付单记录跳转到本地的一个支付模拟页面用户确认“模拟支付成功”后系统将支付结果以异步通知的形式回调后端接口后端更新订单状态并记录支付流水号。把“支付回调”和“订单状态更新”拆开做是对真实电商系统行为的一种高度仿真答辩老师通常会很认可。订单号的生成规则又是一个可以写进论文的细节。不能用数据库自增 id 直接做订单号因为订单号会在支付流水、物流单号等多个场景关联使用。建议使用“时间戳 用户 id 后四位 随机数”的组合生成一个 20 位左右的唯一订单号。如果计算后担心并发下重复在订单表上给订单号字段加唯一索引兜底。3.4 用户权限与登录认证的实现用户模块是很多同学容易忽视的部分实际上在这个销售系统里它承担着整个系统的安全和角色控制。注册模块需要做用户名唯一校验、密码加密存储、图形验证码防刷。密码建议用 BCrypt 加密这是 Spring Security 生态里成熟度高、使用广泛的工具类就算你不在项目里引入完整的 Spring Security也可以用jBCrypt工具类单独做密码加密。登录接口成功之后后端根据用户 id 生成 JWT同时把 token 存一份到 Redis设置过期时间。Redis 里存这份 token 的意义在于“登出失效”能力正常 JWT 是无状态的服务端签发之后在过期前无法撤销把 token 存在 Redis 里用户登出时删除 Redis 中的 token后端在认证拦截器里先查 Redis 是否存在对应 token不存在就认为未登录。这个设计解决了 JWT 的“不可控失效”问题写在论文里是一个加分项。后台管理端不能用和用户端同一套登录逻辑。管理员表和用户表要分开设计登录接口也要单独写一套返回的 token 中通过角色标识进行区分。拦截器拦截所有/api/admin/**路径只有当 token 中的角色是管理员时才能继续访问。这样“用户只能操作自己的数据管理员才能操作全部数据”的权限边界就清晰了。4. 数据库设计与核心表结构4.1 全量表清单与业务关系规划一个能扛住答辩追问的无人机销售系统表结构至少要包含 9 张核心表。我自己在项目中设计了一套完整的表关系列在这里供你参考表名核心职责与其它表的关系user注册用户基本信息被 address、order、cart 引用admin后台管理员账号独立不参与业务核心链路category无人机分类多旋翼/固定翼/穿越机等一对多关联 productproduct无人机 SPU 商品信息关联 category一对多关联 product_specproduct_spec商品规格 SKU版型、价格、库存多对一关联 productcart购物车持久化备用方案关联 user 和 productorder订单主表关联 userorder_item订单明细表多对一关联 order关联 product_specaddress收货地址表关联 userbanner首页轮播图配置独立配置表这 9 张表的关系规划里最核心的是 order 和 order_item 的设计。一个订单主表记录订单总额、订单状态、支付时间、发货时间、收货人快照等一个订单明细表记录每个商品的名称、单价、数量、规格快照。这里有一个电商设计的重要原则订单里的商品信息必须做“快照”而不是查询时实时关联商品表。因为商品价格、名称都可能调整如果实时关联商品表用户查看历史订单的时候看到的就不是下单时的真实数据了。这个细节很多毕设项目不做但只要你做了答辩时就能“甩开同行”。4.2 核心表结构关键字段设计product 无人机商品主表的字段设计除了 id、名称、简介、详情 HTML 之外主要业务字段还包括品牌、型号、分类 id、封面图、主图列表、上下架状态、审核状态、销量、浏览量等。上下架状态和审核状态是分开的两个字段上架前必须先通过审核这是模拟真实商城对商品发布的管理要求。销量和浏览量要分别设置默认值 0并且需要考虑用 Redis 做异步累加。order 订单主表的字段设计建议参考下面的结构CREATE TABLE order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL COMMENT 订单编号, user_id bigint NOT NULL COMMENT 下单用户ID, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, pay_amount decimal(10,2) NOT NULL COMMENT 实付金额, pay_type tinyint DEFAULT NULL COMMENT 支付方式 1-模拟支付 2-模拟支付宝 3-模拟微信, status tinyint NOT NULL COMMENT 订单状态 0-待支付 1-待发货 2-已发货 3-已签收 4-已完成 5-已取消 6-退款中 7-已退款, receiver_name varchar(50) NOT NULL COMMENT 收货人姓名快照, receiver_phone varchar(20) NOT NULL COMMENT 收货人电话快照, receiver_address varchar(255) NOT NULL COMMENT 收货地址快照, pay_time datetime DEFAULT NULL COMMENT 支付时间, delivery_time datetime DEFAULT NULL COMMENT 发货时间, finish_time datetime DEFAULT NULL COMMENT 完成时间, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;order_item 表的关键在于把商品信息做持久化快照不依赖实时查询商品表。所以在字段设计上要把下单当时的“商品名称、商品主图、规格名称、成交单价、购买数量、小计金额”全部存下来。这样的话即使商品后来被删除历史订单的展示也完全不受影响。4.3 表关系设计中的心得与避坑表关系设计中最容易犯的错误是“为了外键而外键”。在真实互联网项目的开发中外键约束通常是不建在数据库层的而是在应用层通过事务保证一致性。理由也很简单外键会影响插入和删除性能同时导致数据库表之间的耦合度非常高给后续业务扩展添堵。毕设论文中可以把这点写进去作为“数据库设计约束考量”。另一个心得是关于逻辑删除。用户表、商品表这类核心业务表不建议做物理删除统一用deleted字段标记逻辑删除。MyBatis-Plus 对逻辑删除有原生支持只要实体上加TableLogic注解日常查询就会自动过滤掉已删除的数据。这样做的直接好处是订单明细中的商品快照不会因为商品被删而查不到数据。5. 本地环境配置与调试运行全流程5.1 环境准备清单与版本搭配在你准备动手跑这个项目之前先确认电脑上的基础环境是否齐备。下面这张清单是我帮你整理的最小可用集版本之间经过兼容性验证环境项推荐版本备注JDK1.88u202 或更高某些新版 IDE 对 JDK 9 的支持有坑Maven3.6.x 或 3.8.x不要用太旧的 3.2容易解析出问题MySQL5.7 或 8.08.0 需要确认时区配置Redis5.x 或 6.xWindows 上可以用解压版 redis-server.exeNode.js14.x 或 16.xVue 2 项目对 Node 版本兼容性较好IDEIntelliJ IDEA 2021前端可选 VS CodeJDK 版本这一点必须强调别下载一个 JDK 17 就来跑 Spring Boot 2.7虽然能跑但是配置参数和字节码版本带来的报错会让你怀疑人生。毕设阶段用最稳定的组合先跑通再考虑升级。5.2 初始化数据库与导入数据脚本拿到项目源代码之后第一步不是打开 IDE而是先把数据库初始化好。在 Navicat 或命令行中创建一个编码为 utf8mb4 的数据库名字建议取drone_sale。然后按顺序导入项目下的 SQL 文件顺序不能乱先建表结构再导入初始化数据。基础数据脚本里一般会预置一个管理员账号、一个测试用户账号、若干无人机分类和商品数据。导入完成后运行下面这条 SQL 验证商品表是否正常SELECT product_name, price, stock FROM product LIMIT 5;如果返回了数据说明 SQL 导入成功。很多同学一上手就启动后端结果启动时报 “Unknown database” 或者 “Table doesnt exist”十有八九是数据库没有创建成功。“先跑 SQL再跑代码”这个顺序一定要遵守。5.3 后端启动过程与三个常见配置坑后端启动步骤非常简单打开 IDEA 导入 Maven 项目等待依赖下载完成修改application.yml中的数据库账号和密码然后运行主启动类。主启动类通常在src/main/java/com/drone/sale/DroneSaleApplication.java直接右键运行即可。第一个常见配置坑是数据库连接的时区问题。MySQL 8.x 对时区敏感application.yml里面要把 url 写成这样url: jdbc:mysql://localhost:3306/drone_sale?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiuseSSLfalse是因为本地开发环境一般没有配置 SSL 证书不关闭会报 SSL 连接警告serverTimezoneAsia/Shanghai是为了避免时间字段差 8 小时的问题。第二个常见配置坑是 Mapper 扫描不到。启动类上不要忘记加MapperScan(com.drone.sale.mapper)注解否则 MyBatis 的 Mapper 接口不会注册到 Spring 容器里启动就会报 “Field mapper in service required a bean of type” 的错误。如果你不是放在启动类上而是逐个用Mapper注解标注接口也可以但每个 Mapper 都要写比较麻烦。第三个坑是 Redis 未启动导致登录接口报错。如果你的项目里引入了购物车缓存那登录模块很可能会尝试连接 Redis。如果 Redis 服务没有启动接口会直接抛连接异常。首次跑通项目时建议先把 Redis 相关功能做成“可降级”的也就是 Redis 不可用时系统还能正常完成商品浏览和下单等环境全部就绪再开启缓存优化。这个降级处理的逻辑写到论文里就是“系统容错设计”。5.4 前端启动与接口联调全流程前端项目一般是一个独立的 Vue 工程目录名可能是drone-front或者vue-admin。第一步是执行npm install安装依赖这一步是前端最容易“卡半小时”的环节。如果网络慢npm 源换成国内镜像会快很多命令如下npm config set registry https://registry.npmmirror.com依赖装完之后执行npm run serve启动开发服务器。默认端口通常为 8080而后端接口也是 8080所以前端项目一般配置的 devServer 端口是 8081。两个项目必须同时跑起来联调才有意义。Vue 前端的代理配置在vue.config.js里通常这样配module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这个配置的作用是前端请求/api/product/list时开发服务器会自动把请求转发到后端 8080 端口的对应接口上同时规避了跨域问题。生产部署的时候前端的dist目录由 Nginx 托管Nginx 再做反向代理到后端服务原理和这里的 devServer 代理是一致的。联调时务必用浏览器按 F12 打开开发者工具查看 Network 面板中的请求和响应。如果后端返回 401检查请求头中是否携带了Authorization: Bearer token如果返回 403大概率是同一路径下角色权限不足如果返回 500直接看 IDEA 控制台最下方的异常栈绝大多数问题都能定位出来。6. 论文撰写与答辩准备要点6.1 毕设论文的合理章节安排与字数分配一份合格的毕设论文围绕这个项目大概需要写 1.5 万字到 2 万字核心章节的建议分配如下。第一章绪论写研究背景和国内外现状字数控制在 2000 字以内别从远古通信技术开始长篇大论第二章需求分析分别从用户、运营、管理员三个视角撰写功能需求和非功能需求配合用例图第三章概要设计重点写系统总体架构图、技术选型对比、功能模块划分第四章详细设计把数据库表结构和核心业务时序图、类图、状态图都放进来这是工作量最大的章节字数占比最大第五章系统实现按功能模块配截图和核心代码片段注意代码不要整段贴只贴关键逻辑第六章测试写测试用例表覆盖正确的接口测试结果和异常测试结果。论文表格的最大禁忌是“截图模糊”。所有页面截图都尽量用系统里的真实页面再截图不要用开发时的半成品页面。各章的表格编号、图片编号、公式编号要保持连续格式问题经常是评阅老师最快能挑出来的硬伤。6.2 答辩现场最高频的 6 个技术问题答辩是一个“讲述 演示 问答”的过程评委问的问题基本逃不出项目本身的业务逻辑和技术选型。我根据往届学生的反馈整理了几个高频问题你可以提前把答案准备好涉及的回答要点我也罗列在下面。第一问为什么使用 Spring Boot 而不是 SSM答案核心是 Spring Boot 简化了配置、内置了容器、简化了部署同时它对 Spring MVC、MyBatis 等生态的整合更顺畅生产效率显著提高。第二问订单超时未支付怎么处理如果项目实现了这个就是亮点如果没实现要有诚实的回应和后续改进方向如果实现了可以用延迟队列或定时任务扫表处理如果没有实现可以坦率说明当前系统通过支付回调保证状态一致超时处理是后续优化方向。第三问项目中你遇到的最大难点是什么不要回答说“都挺顺的”要有具体的技术细节。比较安全的说法是“在处理用户未登录购物车和登录后购物车合并的时候库存并发和数据一致性需要考虑得比较多”或者“在订单状态机的边界条件处理上做了一些设计”。第四问数据库一个用户下多个订单怎么查询性能最优答order 表建 user_id 索引分页查询同时用 Redis 缓存热数据。第五问如果做秒杀或者促销活动你会怎么设计这里暗示要做库存扣减。好的回答要点包括“Redis 预减库存 数据库乐观锁兜底 MQ 异步更新订单”这个套路。第六问系统的安全性如何保证答密码 BCrypt 加密存储、JWT 认证 Redis token 管理、登录验证码防暴力破解、拦截器做角色权限控制。6.3 演示流程要设计成有“反差感”的剧本演示环节是最容易被忽略但回报率很高的环节。不要打开系统找到列表页就给评委开始一顿乱点这样空洞无聊。我建议你把演示流程设计成一个有逻辑的小剧本大约 6 分钟。第一分钟展示项目结构和技术栈第二分钟展示用户注册登录、JWT 返回第三分钟展示商品浏览和购物车操作第四分钟模拟下单和支付回调展示订单状态从待支付变成待发货第五分钟切换到管理端演示商品上下架和新订单发货最后一分钟故意展示一个“错误处理”比如故意把库存改成 0 再下单让系统优雅地弹“库存不足”的提示。这个设计能向评委传递一个信息——你对异常情况也有思考。演示前还要做两件事。第一件事把 Redis 服务提前启动好数据库和前端后端项目先完整跑一遍完整流程确认所有按钮都能点击。第二件事把演示环境的浏览器缩放比例调好图片上传路径、字体大小都要提前检查。曾经有个学生演示前一天数据库被误删演示当场所有模块全挂这种低级失误只要提前完整跑一遍就能避免。7. 定制扩展方向与常见问题实录7.1 常见技术问题速查表这里我把这个项目调试过程中最常遇到的 10 个问题整理成一张速查表。每一个我都对应了解决思路你遇到相同问题时可以直接照做现象根本原因解决方案启动类报 Field mapper in service required a bean缺少 MapperScan 注解启动类上补 MapperScan(com.drone.sale.mapper)数据库访问报 Access denied账号密码错误或权限不足检查 application.yml 中账号密码测试连接后端启动后在页面上访问接口返回 404项目路径前缀不对检查 controller 是否有 RequestMapping(/api)前端所有请求都返回 404前端代理或后端上下文路径不对检查 vue.config.js 代理 target 和后端端口登录后调用下单接口返回 401token 没有传或已过期检查前端 axios 拦截器是否自动附带 token图片上传后无法显示静态资源映射未配置在 WebMvcConfigurer 中添加资源映射中文写入数据库乱码数据库表字符集不对把库表全部改为 utf8mb4连接 url 加 encoding启动时端口被占用其他进程占用了 8080/8081换端口或在任务管理器中结束占用进程Redis 连接失败导致登录失败Redis 未启动启动 redis-server检查 redis 端口和密码下单时库存出现负数没有做并发控制在 service 层加库存扣减前判断 数据库乐观锁7.2 从毕设到面试项目的三条扩展路径如果你不仅想把毕设做出来还想让它成为求职面试中一个能拿得出手的项目那接下来的建议会很有帮助。这个无人机销售系统的代码基础已经具备了比较完整的电商闭环顺着下面三条路径扩展它就能在面试中打出差异化的位置。第一条扩展路径是加消息队列。当用户下单时把“创建订单”的消息发送到消息队列通过异步消费完成库存扣减和支付状态检查。这样接口的响应速度会变快系统的解耦能力也会提升。关键实现是引入消息队列依赖订单创建成功后发布消息消费者去更新库存和订单状态。面试中被问到“你这个系统能抗多少并发”时这个设计就能成为有力的回答支撑。第二条扩展路径是加数据分析功能。在现有订单表和用户表的基础上增加一个管理端的数据统计页用 ECharts 展示每日订单数、销售额、热门无人机 Top10、用户增长趋势。后端通过 SQL 聚合统计前端可视化展示。这条路径实现起来相对简单但对项目的“职场实用感”提升非常明显。第三条扩展路径是加微信小程序端。现有后端 API 已经完成按小程序端的接口规范做一次裁剪再套一层微信登录就能输出一个“PC 管理端 H5 用户端 小程序端”三种端形态覆盖的完整项目。这种多端结构在简历上是能一眼抓住面试官注意力的点。当然这个扩展的工作量较大要对小程序开发有一定熟悉程度建议在基本功扎实之后再动手。7.3 连续踩了几次坑之后我总结的调试心得这个项目我前后帮人调试了不下十次环境踩过的坑五花八门最后沉淀下来的心得其实就三条。第一条遇到启动报错时第一时间看完整异常栈的最上面那个 Caused by不要被满屏的 Exception 吓到90% 的问题都写在 Caused by 的第一行里。第二条前后端联调时先在后端控制台确认请求有没有到达 controller如果没有到达说明是路由或跨域层的问题如果到达了又报错才去查业务代码这一步能帮你少查一整天的冤枉代码。第三条测试环境的数据要养成每天备份的习惯哪怕只是把 SQL 文件存一份放在网盘或本地压缩包里也不至于在演示前夜手忙脚乱。我个人在实际项目复盘中的体会是这类统销售的 Spring Boot 项目最大的学习价值不在“能用”这几个词上而在于通过一个完整的业务链路把 Java 后端主流的开发方式串了一遍。从数据库建模到 REST API 设计从缓存使用到状态机控制再从拦截器鉴权到全局异常处理每一步都踩在一个真实业务系统会遇到的点上。如果你不是为了应付毕业设计而是真的想把 Spring Boot 这条路走顺这套业务就是一份很值得反复吃的练习材料。最后再分享一个小技巧。项目跑通之后不要急着删工程建议你再花两个晚上把下面的代码重点精读一遍订单状态机判断类、用户登录拦截器的实现类、购物车合并逻辑还有产品上下架和库存扣减那一段 service。这几个文件读懂了哪怕项目不再扩展你对 Spring Boot 开发“业务层怎么组织、异常怎么处理、事务怎么控制”的理解也会上一个台阶。