最近帮人跑通了一个 Spring Boot 的二手品牌包在线交易系统项目内容包括完整的程序源码、数据库脚本、调试部署步骤、开发环境配置还附带一篇一万字以上的毕业论文文档。这项目一看就是毕业设计的标准配置但说实话整个流程走下来光是把系统从“能跑”到“跑得顺”里面藏着不少容易踩的坑。写这篇文章主要是把我在开发、部署、调bug过程中积累的实操经验拆解一遍给正在做类似课题或者准备入门 Spring Boot 实战的朋友一些参考。先说说这个系统是干什么的。它是一个基于 Spring Boot 框架的电商类平台只不过交易对象是二手品牌包比如 LV、Gucci 这类二手成色包。用户端可以注册登录、浏览商品、按品牌或价格筛选、加购物车、下单、模拟支付、发布自己的包出售后台管理端可以管理用户、审核商品、处理订单。说白了就是一个垂直领域电商系统的完整简化版。如果你正在学 Spring Boot或者需要做毕业设计拿这个项目当模板来梳理业务逻辑和代码结构会很直观。下面我用几个维度把这个项目从设计到落地的全过程拆给你看重点说清楚为什么这样选、实际开发中卡在哪里。1. 项目整体设计与技术选型1.1 为什么选 Spring Boot 而不是其他框架现在做这类系统Spring Boot 几乎是默认答案了。原因很简单它把 Spring 一堆繁琐的 XML 配置全部交给了自动配置机制项目能快速启动内置 Tomcat 也省去了单独部署到 Web 容器的麻烦。我一开始考虑过传统的 SSMSpring SpringMVC MyBatis组合但配置太多为了一个配置类折腾半天完全没必要。也对比过 PHP 源码方案虽然 PHP 搭建快但类型弱、后期维护难而且做毕设写论文时代码和技术栈的“技术含量”不好写Spring Boot 加 MyBatis 加 MySQL 的搭配在论文里好展开得多。选型的时候还有一个容易忽略的坑版本。现在 Spring Boot 已经从 2.x 升到 3.x 了3.x 强制要求 JDK 17而大部分学校机房和老项目用的是 JDK 8。如果你贸然用 3.x环境没升级就可能直接编译失败。我的经验是稳定优先选 Spring Boot 2.7.x配 JDK 8依赖兼容性最好网上的资料也多真遇到问题容易搜到答案。很多人盲目追求新版本结果连 MyBatis 的 starter 都因为命名变更找不到纯属给自己挖坑。1.2 核心功能模块拆解系统的功能设计决定了数据库和代码结构所以我先列一下模块后面的一切都围绕它们展开。从用户端来说核心模块包括用户注册与登录使用 BCrypt 对密码加密登录成功后使用 JWT 生成 token前端携带 token 请求受限接口。商品展示与检索首页轮播横幅商品列表按品牌、成色、价格区间多条件筛选关键词搜索商品名称和描述。商品管理卖家可以发布包上传多张图片、填品牌、型号、入手价、出售价、成色描述商品默认待审核状态。购物车加入购物车、修改数量、删除商品、计算总价。订单流程从购物车结算或直接购买生成订单订单状态包括待支付、待发货、待收货、已完成、取消还有模拟支付流程。收藏与评价用户收藏商品收到货之后对订单中的商品进行评价评分并写评语。管理端模块用户管理查询用户列表、禁用/启用账号。商品审核管理员通过或退回用户发布的商品。订单管理查看所有订单处理退款、强制关闭异常订单。数据统计简单统计用户数、商品数、交易额用 ECharts 展示趋势图。整个功能设计不算复杂但完整覆盖了一个交易系统应有的全部闭环。这也是毕设评审老师最看重的点流程完整、角色分明、状态清晰。2. 数据库设计与核心数据表2.1 数据表关系设计数据库设计是这类的关键甚至可以说数据库设计做好了代码写着顺一大半。我设计了 7 张核心表表结构并不复杂但每张表的字段和关系都需要服务于业务流程。表名说明关键字段user用户表id, username, password, nickname, role, avatar, statusbag商品表id, seller_id, brand, model, condition, price, original_price, cover_image, description, statuscart购物车表id, user_id, bag_id, quantity, create_timeorders订单表id, order_no, user_id, total_amount, status, create_time, pay_time, receive_timeorder_item订单商品明细表id, order_id, bag_id, price, quantityfavorite收藏表id, user_id, bag_idcomment评价表id, user_id, bag_id, order_id, rating, content关系上一个用户可以拥有多件商品bag 表的 seller_id 外键指向 user一个用户可以下多个订单orders.user_id一个订单包含多个订单项order_item.order_id订单项最终关联到商品order_item.bag_id。购物车和收藏都作为中间表存在记录用户与商品之间的操作关系。我特意把订单和订单明细拆成两张表这样设计是考虑到业务扩展性虽然二手包通常一次只能买一个但以后如果支持多商品合并下单这种结构就不需要大改。还有一点要注意商品表里的价格字段我用的是 DECIMAL(10,2)而没用 DOUBLE避免精度丢失。很多人喜欢用 DOUBLE但在金额计算上一定要用 DECIMAL否则对账时差一分钱都会让你怀疑人生。2.2 核心 SQL 与数据访问实现数据访问层我选的是 MyBatis而不是 Spring Data JPA。因为 MyBatis 的 SQL 直接写出来调优、排查问题都直观而且做毕设答辩时你可以跟老师讲清楚每一条 SQL 的逻辑这是很大的加分项。JPA 虽然省事但自动生成的 SQL 对新手来说像黑盒一旦出现查询不对改起来反而费劲。举一个典型的增删改查例子比如商品列表的分页条件查询select idselectBagList resultTypecom.example.entity.Bag SELECT * FROM bag where if testbrand ! null and brand ! AND brand #{brand} /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if AND status 1 /where ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} /select这里用了动态 SQL前端传入品牌、价格区间参数时MyBatis 会自动拼接条件。使用 LIMIT 做分页。逻辑删除和状态过滤很重要比如 status1 表示审核通过且上架这样就避免查询到未审核或者下架的商品。所有查询都走这条过滤条件而不是在 Java 代码里二次筛选这一条经验可以帮你避免很多数据越权的 bug。再比如订单状态更新因为状态流转有顺序我用 SQL 里加条件来保证只能单向流转update idupdateOrderStatus UPDATE orders SET status #{newStatus} WHERE id #{orderId} AND status #{oldStatus} /update这样即使前端拼错接口后端也不会把“待发货”直接更新成“已完成”保证状态机的严谨性。3. 后端核心实现与关键代码3.1 Spring Boot 项目结构一个清晰的包结构能让代码维护变得很轻松。我用的标准分层结构com.example.shop ├── controller # 接口层接收请求、返回JSON ├── service # 业务逻辑层处理复杂事务 ├── mapper # MyBatis持久层接口对应XML ├── entity # 数据库实体类 ├── dto # 请求和响应的数据对象 ├── config # 配置类如CORS、拦截器、异常处理器 ├── util # 工具类如JWT工具 └── ShopApplication.javacontroller 里只放参数校验和调用 service 的代码不写业务逻辑service 只处理业务不写 SQLmapper 只写数据访问。这套约定俗成的规范新手特别容易犯的错误是在 controller 里直接操作 mapper虽然也能跑但抽离出来之后事务、复用、测试都方便得多。做项目的时候尽量按这个标准来对你以后进团队也有好处。3.2 商品发布与下单流程的实现细节商品发布的 service 里最核心的是图片上传。二手包的成色描述很重要图片必须至少 3 张否则不给提交。我用的是本地存储文件上传后把路径保存到 bag 表的 cover_image 字段并且把原来的文件名做哈希处理防止文件重名覆盖。下单流程是系统里最容易出 bug 的地方因为它涉及购物车数据读取、订单创建、订单明细创建、库存扣减、清空购物车多个步骤任何一步失败都会导致数据不一致。所以我直接加了事务注解。Override Transactional(rollbackFor Exception.class) public Order createOrder(OrderCreateRequest request) { // 1.从购物车查选中的商品列表 ListCartItem cartItems cartMapper.selectCheckedItems(request.getUserId()); // 2.计算总金额并逐一创建 order_item Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(request.getUserId()); order.setTotalAmount(...); order.setStatus(PENDING_PAYMENT); orderMapper.insert(order); // 3.批量插入订单明细 orderItemMapper.batchInsert(order.getId(), cartItems); // 4.修改商品状态为待支付避免重复下单 bagMapper.updateStatusByIds(..., LOCKED); // 5.清空购物车中已结算的商品 cartMapper.deleteByIds(ids); return order; }Transactional 意味着以上 5 步任何一个环节抛异常整个操作会全部回滚不会出现那种“订单多了但库存没扣”的问题。还有一个细节库存扣减不是真的减库存而是把商品状态改成“LOCKED”锁定用户如果超时未支付后台再把它改成上架状态。二手包本来就只有一个库存用状态控制天然适合。3.3 关于“Spring Boot 可以不内置 Tomcat 吗”很多人搜过一个问题“Spring Boot 可以不内置 Tomcat 吗”答案是可以。你如果想把项目打成 war 包丢到服务器上现有的 Tomcat 里运行需要在启动类里做点修改SpringBootApplication public class ShopApplication extends SpringBootServletInitializer { Override protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) { return builder.sources(ShopApplication.class); } // 原生main方法也可以保留 }然后在 pom.xml 里把嵌入式的 Tomcat 改成 provided 就行dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId scopeprovided/scope /dependency但坦白说现在真没有太大必要这么做。内置 Tomcat 自动启动、自动配置端口还能快速打包成可执行 jar用 java -jar 一键运行部署比传统 war 包省太多事。除非服务器上已经有特定的 Tomcat 管理工具必须用 war 部署否则我建议就用 jar 方式跑。不过这个知识点论文里可以写能够体现你了解传统部署方式。4. 调试部署与开发环境搭建4.1 从零搭建开发环境如果你从零开始搭环境我的步骤是这样的先装 JDK 8再装 Maven 3.6.3然后装 IDEA 或者 Eclipse。环境变量方面记得配好 JAVA_HOME、M2_HOME 和 PATH。Maven 是一个特别容易卡住新手的地方因为中央仓库在国外下载依赖很慢。解决办法是在 settings.xml 里配置阿里云镜像mirror idaliyunmaven/id mirrorOfcentral/mirrorOf urlhttps://maven.aliyun.com/repository/public/url /mirror配置好镜像后依赖下载速度能从“龟速”直接变成“秒下”。另外IDEA 里一定要把 Maven 设置里的“自动导入”打开不然改 pom 之后每次都要手动 reload很麻烦。数据库方面我用的是 MySQL 5.7。你如果选 MySQL 8.x注意连接驱动版本要对应驱动类名从 com.mysql.jdbc.Driver 换成了 com.mysql.cj.jdbc.Driver连接 URL 也要带 serverTimezone 参数否则会报时区错误。这是数据库连接最常见的坑之一。4.2 打包部署到云服务器整个调试阶段我在本地跑通之后打包部署也没出太大问题。流程很简单mvn clean package -DskipTests然后拿到 target 目录下的 shop.jar上传到 Linux 服务器直接用命令跑java -jar shop.jar --spring.profiles.activeprod这里我建议把配置信息外置比如数据库密码不要写死在 application.properties 里用环境变量注入更安全。打包的时候还需要注意一个细节项目依赖的前端静态资源如果已经打成 jar 包里的就无所谓但如果你是前后端分离开发记得把前端 build 完的 dist 文件夹放到 static 目录下否则会 404。线上运行的话可以借助 systemd 做开机自启或者用一个简单的 shell 脚本来启动和挂掉自动重启。但毕设演示阶段只要 java -jar 能跑起来然后访问 http://服务器IP:8080 能看到界面就足够了。4.3 常见问题排查与避坑指南我在调试过程中遇到过不少报错这里整理成一份问题速查表按我遇到过的概率排序问题现象原因解决方法启动报端口被占用8080 被其他程序占用用netstat -ano找 PID杀掉进程或者改server.port报错 Failed to configure a DataSource数据库连接配置不对或者依赖少了 jdbc starter检查 URL、用户名、密码确保 application.yml 里配置了 spring.datasource页面中文乱码返回 JSON 时响应编码不对在 application.properties 加server.servlet.encoding.forcetrue或用RequestMapping(produces application/json;charsetUTF-8)MyBatis 绑定异常: Invalid bound statementmapper.xml 没有放在和 mapper 接口对应的包下或者 namespace 写错检查 resources 目录下 mapper xml 的 namespace 是否对应接口全类名只跑了某个单元测试却把整个工程编译失败Maven 配置了打包测试而测试类里有环境依赖mvn package -DskipTests跳过测试上传图片时文件名中文乱码Tomcat 默认编码和文件上传编码不一致配置spring.servlet.multipart相关属性并在 controller 里用MultipartFile.getOriginalFilename()时注意转码Spring Boot 版本过高导致依赖不兼容3.x 强制 JDK17部分旧版 starter 名称改变换成 2.7.x 版本或者升级到对应组件版本还有一件事必须提醒如果你从别人那里拿到项目源码第一件事就是看一眼 pom.xml 里 Spring Boot 的 parent 版本和自己的 JDK 是否匹配不然编译必挂。这个操作我每次都做能省下至少半小时的无意义排查。5. 论文文档的写作思路5.1 论文结构安排这个系统附带了一篇一万字以上的论文。很多人拿到项目后发现“系统能跑但论文不知道怎么写”或者自己不会写。我的写作思路是紧扣实际系统来写避免空谈。正规结构大概这样绪论交代背景二手交易市场规模扩大但垂直品类的平台不多介绍用技术手段解决信息不对称问题。相关技术介绍Spring Boot 的优点、MyBatis 的映射机制、MySQL 的事务和索引原理、JWT 的身份认证流程。需求分析从用户角色出发画出用例图说明每个角色的核心功能。这一章最好结合页面截图和流程图老师一眼看到你的工作量。系统设计模块划分、架构图、数据库 ER 图和数据表字段解释。系统实现分模块贴代码和截图重点写订单流程、商品检索、权限验证的实现细节。系统测试写测试用例表格列出测试项、输入、预期输出、实际输出、结论。再写一点性能测试比如用 JMeter 测接口响应时间。总结与展望总结完成了什么指出不足比如支付是模拟的、没有接入真实物流等。5.2 如何让论文更丰满一万字听起来多其实写到实现部分自然就撑起来了。每一章配两张以上图表比如功能结构图、流程图、时序图、数据库 ER 图图多了字数自然上去。测试部分列出表格也很占篇幅而且显得严谨。写实现部分时不要大段贴完整代码而是贴核心代码片段并逐行解释。比如下单事务你怎么处理的为什么要加 Transactional不加以什么后果。再比如电商系统最看重的商品检索你怎么用动态 SQL 完成多条件筛选底层索引怎么设计的。这些细节都是论文的加分项也是答辩时能讲出东西的地方。6. 项目完整性与获取建议6.1 项目包含哪些内容这套系统做下来最后交付的内容其实很标准化一个完整的 Spring Boot 工程源码、一个 MySQL 数据库脚本、一份环境部署说明、一份 1 万字以上的论文文档以及系统的最终界面截图。源码拿到手导入 IDEA 后按说明改一下数据库密码重启就能跑起来。数据库脚本里已经插入了测试用户、测试商品和订单数据省去了自己一条条造数据的麻烦。需要说明的是现在网上确实有不少这类项目资源有的免费有的收费。我的建议是不要光看标题先看它的功能覆盖是否符合你的需求再看数据库脚本是否完整最后看部署文档有没有写清楚版本号。最怕的是拿到一个残缺品运行起来缺这个表缺那个包调试到心态崩溃那才是真正的灾难。6.2 如何快速验证项目能不能跑拿到项目后我一般按 3 分钟法则来验证先看 pom.xml 的 Spring Boot 版本和 JDK 版本再去看 application.properties 里的数据库配置是否和你本地 MySQL 一致最后打开系统首页挨个点一遍注册、登录、发布商品、下单。只要这些主链路跑通剩下的细节都可以慢慢打磨。如果连项目启动都报 DataSource 错误那就先检查数据库连接90% 的问题是密码、主机地址或端口写错。我实际操作中的体会是做这种系统最花时间的往往不是代码而是环境。尤其是当你换了电脑、换了数据库版本、换了 Maven 源各种莫名其妙的兼容问题就来了。所以我很建议你在项目刚拿到手的时候就完整跑一遍流程把自己设成“环境排查侠”把所有坑提前踩一遍后续开发就会非常顺。最后再分享一个小技巧如果你用的是 IDEA在 Debug 模式下把断点打到 Service 层就能清楚看到整个流程的数据流转排查问题的效率翻倍。这个技巧对于理解 Spring Boot 的请求处理链路特别有用。 
长河君 · 2026/10/9 5:11:04 · 阅读 1.2k Spring Boot二手品牌包交易系统实战：从数据库设计到部署避坑
最近帮人跑通了一个 Spring Boot 的二手品牌包在线交易系统项目内容包括完整的程序源码、数据库脚本、调试部署步骤、开发环境配置还附带一篇一万字以上的毕业论文文档。这项目一看就是毕业设计的标准配置但说实话整个流程走下来光是把系统从“能跑”到“跑得顺”里面藏着不少容易踩的坑。写这篇文章主要是把我在开发、部署、调bug过程中积累的实操经验拆解一遍给正在做类似课题或者准备入门 Spring Boot 实战的朋友一些参考。先说说这个系统是干什么的。它是一个基于 Spring Boot 框架的电商类平台只不过交易对象是二手品牌包比如 LV、Gucci 这类二手成色包。用户端可以注册登录、浏览商品、按品牌或价格筛选、加购物车、下单、模拟支付、发布自己的包出售后台管理端可以管理用户、审核商品、处理订单。说白了就是一个垂直领域电商系统的完整简化版。如果你正在学 Spring Boot或者需要做毕业设计拿这个项目当模板来梳理业务逻辑和代码结构会很直观。下面我用几个维度把这个项目从设计到落地的全过程拆给你看重点说清楚为什么这样选、实际开发中卡在哪里。1. 项目整体设计与技术选型1.1 为什么选 Spring Boot 而不是其他框架现在做这类系统Spring Boot 几乎是默认答案了。原因很简单它把 Spring 一堆繁琐的 XML 配置全部交给了自动配置机制项目能快速启动内置 Tomcat 也省去了单独部署到 Web 容器的麻烦。我一开始考虑过传统的 SSMSpring SpringMVC MyBatis组合但配置太多为了一个配置类折腾半天完全没必要。也对比过 PHP 源码方案虽然 PHP 搭建快但类型弱、后期维护难而且做毕设写论文时代码和技术栈的“技术含量”不好写Spring Boot 加 MyBatis 加 MySQL 的搭配在论文里好展开得多。选型的时候还有一个容易忽略的坑版本。现在 Spring Boot 已经从 2.x 升到 3.x 了3.x 强制要求 JDK 17而大部分学校机房和老项目用的是 JDK 8。如果你贸然用 3.x环境没升级就可能直接编译失败。我的经验是稳定优先选 Spring Boot 2.7.x配 JDK 8依赖兼容性最好网上的资料也多真遇到问题容易搜到答案。很多人盲目追求新版本结果连 MyBatis 的 starter 都因为命名变更找不到纯属给自己挖坑。1.2 核心功能模块拆解系统的功能设计决定了数据库和代码结构所以我先列一下模块后面的一切都围绕它们展开。从用户端来说核心模块包括用户注册与登录使用 BCrypt 对密码加密登录成功后使用 JWT 生成 token前端携带 token 请求受限接口。商品展示与检索首页轮播横幅商品列表按品牌、成色、价格区间多条件筛选关键词搜索商品名称和描述。商品管理卖家可以发布包上传多张图片、填品牌、型号、入手价、出售价、成色描述商品默认待审核状态。购物车加入购物车、修改数量、删除商品、计算总价。订单流程从购物车结算或直接购买生成订单订单状态包括待支付、待发货、待收货、已完成、取消还有模拟支付流程。收藏与评价用户收藏商品收到货之后对订单中的商品进行评价评分并写评语。管理端模块用户管理查询用户列表、禁用/启用账号。商品审核管理员通过或退回用户发布的商品。订单管理查看所有订单处理退款、强制关闭异常订单。数据统计简单统计用户数、商品数、交易额用 ECharts 展示趋势图。整个功能设计不算复杂但完整覆盖了一个交易系统应有的全部闭环。这也是毕设评审老师最看重的点流程完整、角色分明、状态清晰。2. 数据库设计与核心数据表2.1 数据表关系设计数据库设计是这类的关键甚至可以说数据库设计做好了代码写着顺一大半。我设计了 7 张核心表表结构并不复杂但每张表的字段和关系都需要服务于业务流程。表名说明关键字段user用户表id, username, password, nickname, role, avatar, statusbag商品表id, seller_id, brand, model, condition, price, original_price, cover_image, description, statuscart购物车表id, user_id, bag_id, quantity, create_timeorders订单表id, order_no, user_id, total_amount, status, create_time, pay_time, receive_timeorder_item订单商品明细表id, order_id, bag_id, price, quantityfavorite收藏表id, user_id, bag_idcomment评价表id, user_id, bag_id, order_id, rating, content关系上一个用户可以拥有多件商品bag 表的 seller_id 外键指向 user一个用户可以下多个订单orders.user_id一个订单包含多个订单项order_item.order_id订单项最终关联到商品order_item.bag_id。购物车和收藏都作为中间表存在记录用户与商品之间的操作关系。我特意把订单和订单明细拆成两张表这样设计是考虑到业务扩展性虽然二手包通常一次只能买一个但以后如果支持多商品合并下单这种结构就不需要大改。还有一点要注意商品表里的价格字段我用的是 DECIMAL(10,2)而没用 DOUBLE避免精度丢失。很多人喜欢用 DOUBLE但在金额计算上一定要用 DECIMAL否则对账时差一分钱都会让你怀疑人生。2.2 核心 SQL 与数据访问实现数据访问层我选的是 MyBatis而不是 Spring Data JPA。因为 MyBatis 的 SQL 直接写出来调优、排查问题都直观而且做毕设答辩时你可以跟老师讲清楚每一条 SQL 的逻辑这是很大的加分项。JPA 虽然省事但自动生成的 SQL 对新手来说像黑盒一旦出现查询不对改起来反而费劲。举一个典型的增删改查例子比如商品列表的分页条件查询select idselectBagList resultTypecom.example.entity.Bag SELECT * FROM bag where if testbrand ! null and brand ! AND brand #{brand} /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if AND status 1 /where ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} /select这里用了动态 SQL前端传入品牌、价格区间参数时MyBatis 会自动拼接条件。使用 LIMIT 做分页。逻辑删除和状态过滤很重要比如 status1 表示审核通过且上架这样就避免查询到未审核或者下架的商品。所有查询都走这条过滤条件而不是在 Java 代码里二次筛选这一条经验可以帮你避免很多数据越权的 bug。再比如订单状态更新因为状态流转有顺序我用 SQL 里加条件来保证只能单向流转update idupdateOrderStatus UPDATE orders SET status #{newStatus} WHERE id #{orderId} AND status #{oldStatus} /update这样即使前端拼错接口后端也不会把“待发货”直接更新成“已完成”保证状态机的严谨性。3. 后端核心实现与关键代码3.1 Spring Boot 项目结构一个清晰的包结构能让代码维护变得很轻松。我用的标准分层结构com.example.shop ├── controller # 接口层接收请求、返回JSON ├── service # 业务逻辑层处理复杂事务 ├── mapper # MyBatis持久层接口对应XML ├── entity # 数据库实体类 ├── dto # 请求和响应的数据对象 ├── config # 配置类如CORS、拦截器、异常处理器 ├── util # 工具类如JWT工具 └── ShopApplication.javacontroller 里只放参数校验和调用 service 的代码不写业务逻辑service 只处理业务不写 SQLmapper 只写数据访问。这套约定俗成的规范新手特别容易犯的错误是在 controller 里直接操作 mapper虽然也能跑但抽离出来之后事务、复用、测试都方便得多。做项目的时候尽量按这个标准来对你以后进团队也有好处。3.2 商品发布与下单流程的实现细节商品发布的 service 里最核心的是图片上传。二手包的成色描述很重要图片必须至少 3 张否则不给提交。我用的是本地存储文件上传后把路径保存到 bag 表的 cover_image 字段并且把原来的文件名做哈希处理防止文件重名覆盖。下单流程是系统里最容易出 bug 的地方因为它涉及购物车数据读取、订单创建、订单明细创建、库存扣减、清空购物车多个步骤任何一步失败都会导致数据不一致。所以我直接加了事务注解。Override Transactional(rollbackFor Exception.class) public Order createOrder(OrderCreateRequest request) { // 1.从购物车查选中的商品列表 ListCartItem cartItems cartMapper.selectCheckedItems(request.getUserId()); // 2.计算总金额并逐一创建 order_item Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(request.getUserId()); order.setTotalAmount(...); order.setStatus(PENDING_PAYMENT); orderMapper.insert(order); // 3.批量插入订单明细 orderItemMapper.batchInsert(order.getId(), cartItems); // 4.修改商品状态为待支付避免重复下单 bagMapper.updateStatusByIds(..., LOCKED); // 5.清空购物车中已结算的商品 cartMapper.deleteByIds(ids); return order; }Transactional 意味着以上 5 步任何一个环节抛异常整个操作会全部回滚不会出现那种“订单多了但库存没扣”的问题。还有一个细节库存扣减不是真的减库存而是把商品状态改成“LOCKED”锁定用户如果超时未支付后台再把它改成上架状态。二手包本来就只有一个库存用状态控制天然适合。3.3 关于“Spring Boot 可以不内置 Tomcat 吗”很多人搜过一个问题“Spring Boot 可以不内置 Tomcat 吗”答案是可以。你如果想把项目打成 war 包丢到服务器上现有的 Tomcat 里运行需要在启动类里做点修改SpringBootApplication public class ShopApplication extends SpringBootServletInitializer { Override protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) { return builder.sources(ShopApplication.class); } // 原生main方法也可以保留 }然后在 pom.xml 里把嵌入式的 Tomcat 改成 provided 就行dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId scopeprovided/scope /dependency但坦白说现在真没有太大必要这么做。内置 Tomcat 自动启动、自动配置端口还能快速打包成可执行 jar用 java -jar 一键运行部署比传统 war 包省太多事。除非服务器上已经有特定的 Tomcat 管理工具必须用 war 部署否则我建议就用 jar 方式跑。不过这个知识点论文里可以写能够体现你了解传统部署方式。4. 调试部署与开发环境搭建4.1 从零搭建开发环境如果你从零开始搭环境我的步骤是这样的先装 JDK 8再装 Maven 3.6.3然后装 IDEA 或者 Eclipse。环境变量方面记得配好 JAVA_HOME、M2_HOME 和 PATH。Maven 是一个特别容易卡住新手的地方因为中央仓库在国外下载依赖很慢。解决办法是在 settings.xml 里配置阿里云镜像mirror idaliyunmaven/id mirrorOfcentral/mirrorOf urlhttps://maven.aliyun.com/repository/public/url /mirror配置好镜像后依赖下载速度能从“龟速”直接变成“秒下”。另外IDEA 里一定要把 Maven 设置里的“自动导入”打开不然改 pom 之后每次都要手动 reload很麻烦。数据库方面我用的是 MySQL 5.7。你如果选 MySQL 8.x注意连接驱动版本要对应驱动类名从 com.mysql.jdbc.Driver 换成了 com.mysql.cj.jdbc.Driver连接 URL 也要带 serverTimezone 参数否则会报时区错误。这是数据库连接最常见的坑之一。4.2 打包部署到云服务器整个调试阶段我在本地跑通之后打包部署也没出太大问题。流程很简单mvn clean package -DskipTests然后拿到 target 目录下的 shop.jar上传到 Linux 服务器直接用命令跑java -jar shop.jar --spring.profiles.activeprod这里我建议把配置信息外置比如数据库密码不要写死在 application.properties 里用环境变量注入更安全。打包的时候还需要注意一个细节项目依赖的前端静态资源如果已经打成 jar 包里的就无所谓但如果你是前后端分离开发记得把前端 build 完的 dist 文件夹放到 static 目录下否则会 404。线上运行的话可以借助 systemd 做开机自启或者用一个简单的 shell 脚本来启动和挂掉自动重启。但毕设演示阶段只要 java -jar 能跑起来然后访问 http://服务器IP:8080 能看到界面就足够了。4.3 常见问题排查与避坑指南我在调试过程中遇到过不少报错这里整理成一份问题速查表按我遇到过的概率排序问题现象原因解决方法启动报端口被占用8080 被其他程序占用用netstat -ano找 PID杀掉进程或者改server.port报错 Failed to configure a DataSource数据库连接配置不对或者依赖少了 jdbc starter检查 URL、用户名、密码确保 application.yml 里配置了 spring.datasource页面中文乱码返回 JSON 时响应编码不对在 application.properties 加server.servlet.encoding.forcetrue或用RequestMapping(produces application/json;charsetUTF-8)MyBatis 绑定异常: Invalid bound statementmapper.xml 没有放在和 mapper 接口对应的包下或者 namespace 写错检查 resources 目录下 mapper xml 的 namespace 是否对应接口全类名只跑了某个单元测试却把整个工程编译失败Maven 配置了打包测试而测试类里有环境依赖mvn package -DskipTests跳过测试上传图片时文件名中文乱码Tomcat 默认编码和文件上传编码不一致配置spring.servlet.multipart相关属性并在 controller 里用MultipartFile.getOriginalFilename()时注意转码Spring Boot 版本过高导致依赖不兼容3.x 强制 JDK17部分旧版 starter 名称改变换成 2.7.x 版本或者升级到对应组件版本还有一件事必须提醒如果你从别人那里拿到项目源码第一件事就是看一眼 pom.xml 里 Spring Boot 的 parent 版本和自己的 JDK 是否匹配不然编译必挂。这个操作我每次都做能省下至少半小时的无意义排查。5. 论文文档的写作思路5.1 论文结构安排这个系统附带了一篇一万字以上的论文。很多人拿到项目后发现“系统能跑但论文不知道怎么写”或者自己不会写。我的写作思路是紧扣实际系统来写避免空谈。正规结构大概这样绪论交代背景二手交易市场规模扩大但垂直品类的平台不多介绍用技术手段解决信息不对称问题。相关技术介绍Spring Boot 的优点、MyBatis 的映射机制、MySQL 的事务和索引原理、JWT 的身份认证流程。需求分析从用户角色出发画出用例图说明每个角色的核心功能。这一章最好结合页面截图和流程图老师一眼看到你的工作量。系统设计模块划分、架构图、数据库 ER 图和数据表字段解释。系统实现分模块贴代码和截图重点写订单流程、商品检索、权限验证的实现细节。系统测试写测试用例表格列出测试项、输入、预期输出、实际输出、结论。再写一点性能测试比如用 JMeter 测接口响应时间。总结与展望总结完成了什么指出不足比如支付是模拟的、没有接入真实物流等。5.2 如何让论文更丰满一万字听起来多其实写到实现部分自然就撑起来了。每一章配两张以上图表比如功能结构图、流程图、时序图、数据库 ER 图图多了字数自然上去。测试部分列出表格也很占篇幅而且显得严谨。写实现部分时不要大段贴完整代码而是贴核心代码片段并逐行解释。比如下单事务你怎么处理的为什么要加 Transactional不加以什么后果。再比如电商系统最看重的商品检索你怎么用动态 SQL 完成多条件筛选底层索引怎么设计的。这些细节都是论文的加分项也是答辩时能讲出东西的地方。6. 项目完整性与获取建议6.1 项目包含哪些内容这套系统做下来最后交付的内容其实很标准化一个完整的 Spring Boot 工程源码、一个 MySQL 数据库脚本、一份环境部署说明、一份 1 万字以上的论文文档以及系统的最终界面截图。源码拿到手导入 IDEA 后按说明改一下数据库密码重启就能跑起来。数据库脚本里已经插入了测试用户、测试商品和订单数据省去了自己一条条造数据的麻烦。需要说明的是现在网上确实有不少这类项目资源有的免费有的收费。我的建议是不要光看标题先看它的功能覆盖是否符合你的需求再看数据库脚本是否完整最后看部署文档有没有写清楚版本号。最怕的是拿到一个残缺品运行起来缺这个表缺那个包调试到心态崩溃那才是真正的灾难。6.2 如何快速验证项目能不能跑拿到项目后我一般按 3 分钟法则来验证先看 pom.xml 的 Spring Boot 版本和 JDK 版本再去看 application.properties 里的数据库配置是否和你本地 MySQL 一致最后打开系统首页挨个点一遍注册、登录、发布商品、下单。只要这些主链路跑通剩下的细节都可以慢慢打磨。如果连项目启动都报 DataSource 错误那就先检查数据库连接90% 的问题是密码、主机地址或端口写错。我实际操作中的体会是做这种系统最花时间的往往不是代码而是环境。尤其是当你换了电脑、换了数据库版本、换了 Maven 源各种莫名其妙的兼容问题就来了。所以我很建议你在项目刚拿到手的时候就完整跑一遍流程把自己设成“环境排查侠”把所有坑提前踩一遍后续开发就会非常顺。最后再分享一个小技巧如果你用的是 IDEA在 Debug 模式下把断点打到 Service 层就能清楚看到整个流程的数据流转排查问题的效率翻倍。这个技巧对于理解 Spring Boot 的请求处理链路特别有用。