简介：电商后端开发中，交易系统的数据一致性一直是工程实践的核心挑战。SpringBoot作为Java生态主流的微服务开发框架，以其自动化配置和快速部署能力，成为构建中小型交易系统的首选。在抢购、限量商品等场景下，库存超卖、重复支付等问题需要从数据库原子扣减、缓存中间件和幂等设计等原理层面入手解决。本文以潮玩交易系统为例，结合SpringBoot、MyBatis-Plus、Redis与Lua脚本，讲解订单模块拆分、数据库表设计、JWT鉴权、防超卖扣减及模拟支付回调等完整实现路径，帮助开发者快速掌握一套可落地的电商后端解决方案。
1. 潮玩交易系统：为什么选这个题，以及它到底在解决什么
潮玩（盲盒、限量手办、积木熊）交易里最痛的一件事是信息不对称：同款在不同平台差价能到一倍，卖家怕遇到到手刀，买家怕买到假货。SpringBoot 基于 Java 的潮玩交易系统这个选题，本质上就是做一个带库存、订单、支付、验货流程的二手/新品电商后端，用 SpringBoot 框架解决「配置地狱」，用 Java 生态解决「毕业设计/答辩对完整性的要求」。这篇写给正在做这个题目的毕业生，也写给想用一个完整项目理解 SpringBoot 分层设计的新手。我会从模块拆分、表设计、下单链路、防超卖，一路讲到论文写作和答辩踩坑，目标是让你照着这条路能把系统跑起来，也能把论文写得有底气。
2. 用 SpringBoot 搭建潮玩交易后端：模块拆分与数据库表设计
2.1 为什么选 SpringBoot + Java，以及它的边界
SpringBoot 框架在毕设和中小型项目里的地位不用多说。它内嵌 Tomcat，打一个 jar 就能启动，不用像 SSM 时代那样先装 Tomcat、再配 web.xml；Maven 管依赖，MyBatis-Plus 管 CRUD，开发效率比传统 SSH 高一大截。而 Java 本身在高校课程和面试题里出现频率最高，选它意味着你复习八股和答辩被提问时，网上能查到的资料最多。这个选择题其实不是技术题，是风险题。
但 SpringBoot 也有边界。它本质上是一个「粘合层」，本身不解决业务问题。潮玩交易系统的核心难点不在框架，而在交易状态、库存扣减和验货流程。我一般把这个系统分成三块：用户与权限、商品与验货、订单与支付。框架负责把这三块快速串起来，业务逻辑还是得自己一行行写。下面这套模块划分，是我按这个思路做过多次的方案。
2.2 模块怎么拆：按业务边界，别按三层架构堆
很多同学的 SpringBoot 项目结构是 controller / service / mapper 各建一个包，然后所有类全扔进去。我可以直接说：单表 CRUD 这样写没问题，但一旦写到订单状态流转和支付回调，这种结构就会乱套。常见做法是按业务域拆包，让「改一个功能只动一个包」成为可能。
- common：统一返回结果 Result、全局异常处理、工具类。所有接口都返回统一的 code/message/data 结构，前端才好做拦截。
- user：登录注册、地址管理。潮玩交易里有「卖家」和「买家」两种身份，最好在 user 表里加一个 role 字段，而不是拆两张表。
- product：商品上架、商品详情、验货报告。潮玩商品比普通商品多几个属性：品牌、系列、是否隐藏款、限量编号、尺寸。
- order：购物车、下单、订单状态流转。状态机至少要有：待支付、已支付、验货中、已发货、已签收、已取消。
- pay：模拟支付与支付回调。毕设不要接真实支付，但要实现「生成支付单 -> 回调 -> 修改订单状态」的完整流程，不要只在 controller 里 new 一个订单。
- file：图片与验货报告上传。单独拆出来是为了统一存储路径和 URL 映射。
2.3 数据库表设计：核心表与字段清单
表不要一次建十几张，先保证四张核心表：user、product、order、order_item，再加一张 cart 购物车是为了演示方便。
user 表：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键，自增 |
| username | varchar(32) | 登录名，唯一 |
| password | varchar(64) | BCrypt 加密，不要明文 |
| role | tinyint | 1 买家 2 卖家 |
| balance | decimal(10,2) | 账户余额，模拟支付用 |
| created_at | datetime | 注册时间 |
product 表：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| seller_id | bigint | 卖家 id |
| name | varchar(128) | 商品标题 |
| brand | varchar(32) | 品牌，如泡泡玛特、52TOYS |
| series | varchar(32) | 系列名 |
| is_hidden | tinyint | 是否隐藏款 |
| price | decimal(10,2) | 售价 |
| stock | int | 库存，限量款可能只有 1 到 50 |
| report_url | varchar(255) | 验货报告图片路径 |
| status | tinyint | 0 下架 1 在售 2 售罄 |
| version | int | 乐观锁版本号，防超卖用 |
order 表：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| order_no | varchar(32) | 业务订单号，唯一，不能直接用自增 id |
| user_id | bigint | 买家 id |
| product_id | bigint | 商品 id，一个订单只买一个潮玩 |
| quantity | int | 数量 |
| total_amount | decimal(10,2) | 总金额 |
| status | tinyint | 0 待支付 1 已支付 2 验货中 3 已发货 4 已签收 5 已取消 |
| address | varchar(255) | 收货地址快照 |
| created_at | datetime | 创建时间 |
三个注意点。第一，订单号不要用自增 id，答辩时这是经典扣分项，因为自增 id 会把系统订单量直接暴露给别人，而且在幂等和分布式环境下不可靠。建议生成规则：日期 + 用户 id 后四位 + 随机数。第二，address 要做「快照」，也就是下单那一刻把地址拷贝进订单，而不是关联地址表，否则用户改地址会影响历史订单。第三，balance 字段只在模拟支付阶段用，真实项目不会把金额直接存 user 表，但毕设里这样最直观。
2.4 Maven 项目结构与配置文件：开发环境一次跑通
pom.xml 里最关键的几个依赖：
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.5</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> </dependencies>这里我故意锁了 SpringBoot 2.7.18，而不是最新的 3.x。原因是很多同学跟着 2024 年之后的新视频装 SpringBoot 3.x，结果发现 javax.servlet 变成了 jakarta.servlet、MyBatis-Plus 版本不兼容，第一周就卡在启动上。毕设求稳，2.7.18 是 2.x 最后一个版本，资料最全，网上能搜到的答案最多。Maven 构建方法也最成熟，按 standard 目录布局放 src/main/java 和 src/main/resources 就行。
application.yml 配套配置：
server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/toy_trade ?useUnicode=true &characterEncoding=utf8 &serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 redis: host: localhost port: 6379 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImplurl 里的三个参数分别解决：中文字符集乱码、MySQL 8.0 驱动类名变更、时区导致的 datetime 偏差。driver-class-name 用 com.mysql.cj.jdbc.Driver，不要用老教程里的 com.mysql.jdbc.Driver，后者在 MySQL 8.x 下直接抛异常。mybatis-plus 的 log-impl 打开 SQL 日志，调试时能直接看到每条实际执行的语句，我开发环境开着、上线前注释掉。
3. 交易链路代码落地：登录、验货报告上传、购物车与下单
3.1 用户登录与 JWT 鉴权：拦截器这样配才不会漏接口
登录接口返回一个 token，前端每次请求都带上，后端用拦截器统一校验。先写一个 JwtUtil：
public class JwtUtil { private static final SecretKey KEY = Keys.hmacShaKeyFor( "toy-trade-secret-key-please-change-32bytes".getBytes(StandardCharsets.UTF_8)); public static String createToken(Long userId, String username) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("username", username) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 1000L * 60 * 60 * 24)) .signWith(KEY, SignatureAlgorithm.HS256) .compact(); } public static Claims parseToken(String token) { return Jwts.parserBuilder().setSigningKey(KEY).build() .parseClaimsJws(token).getBody(); } }逻辑说明：createToken 把用户 id 放进 subject，把用户名放进 claim，过期时间设 24 小时。parseToken 用于拦截器里解析并校验签名，解析失败会抛 JwtException，由全局异常处理器统一返回 401。密钥我写的是 42 字节的占位字符串，实际项目里应该放到配置文件用 @Value 注入，别写死在类里。
有了工具类，再写拦截器注册。常见做法是定义 WebMvcConfigurer 的 addInterceptors：
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new JwtInterceptor()) .addPathPatterns("/api/**") .excludePathPatterns("/api/user/login", "/api/user/register", "/api/product/list", "/api/product/detail/**"); } }参数说明：addPathPatterns 拦截所有 /api 下的接口，登录、注册、商品列表和详情放行。一个最容易犯的错是忘了排除预检请求，前端如果做的是前后端分离，跨域 OPTIONS 请求会被拦截器卡掉，表现为「登录成功了，但所有业务接口都报 401」。我在 JwtInterceptor 里第一个判断就是if ("OPTIONS".equals(request.getMethod())) return true;。
3.2 商品上架与验货报告上传：本地存储别踩绝对路径的坑
商品上架接口接收一个 multipart 表单，包含商品信息和上传的图片文件：
@PostMapping("/api/product/add") @RequireRole("SELLER") public Result<Product> addProduct(@RequestParam("file") MultipartFile file, @ModelAttribute Product product) { String imageUrl = fileService.save(file); product.setImageUrl(imageUrl); productService.save(product); return Result.success(product); }fileService.save 的细节：
public String save(MultipartFile file) { String original = file.getOriginalFilename(); String ext = original != null ? original.substring(original.lastIndexOf(".")) : ".jpg"; String filename = System.currentTimeMillis() + "-" + UUID.randomUUID().toString().replace("-", "") + ext; String dateDir = new SimpleDateFormat("yyyyMMdd").format(new Date()); File dir = new File(UPLOAD_DIR + dateDir); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir, filename)); return "/uploads/" + dateDir + "/" + filename; }说明两个参数坑。第一，文件名不能用原始文件名，否则不同用户传同名图片会互相覆盖，这里用时间戳加 UUID 生成唯一名。第二，UPLOAD_DIR 必须用配置项注入，不能写死成 D:/xxx 或 /root/xxx，因为本机 Windows 能跑、部署到 Linux 服务器就 404。我一般写成file.upload-dir=/data/toy-trade/uploads，然后用 @Value 读取。配合一个静态资源映射，把 /uploads/** 指到磁盘目录，浏览器才能访问到图片：
@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/uploads/**") .addResourceLocations("file:" + uploadDir); }addResourceLocations 的末尾必须带斜杠，file:前缀不能省略，这两个地方写错任何一个，图片都会 404，而且日志里看不到任何报错，是典型的「显示正常但访问不了」的玄学问题。
3.3 购物车与下单：事务边界和库存扣减一起想
购物车只是一个中间状态，真正的业务是下单。下单接口要做三件事：往 order 表插一条数据、扣减库存、清理购物车。这三件事必须在一个事务里，否则用户下单成功但库存没扣，或者库存扣了但订单没生成，全都会出大事故。
@Service public class OrderService { @Resource private ProductMapper productMapper; @Resource private OrderMapper orderMapper; @Transactional(rollbackFor = Exception.class) public Order createOrder(Long userId, Long productId, Integer quantity, String address) { Product product = productMapper.selectById(productId); if (product == null || product.getStatus() != 1) { throw new BizException("商品不存在或已下架"); } int rows = productMapper.deductStock(productId, quantity); if (rows == 0) { throw new BizException("库存不足"); } Order order = new Order(); order.setOrderNo(generateOrderNo(userId)); order.setUserId(userId); order.setProductId(productId); order.setQuantity(quantity); order.setTotalAmount(product.getPrice().multiply(BigDecimal.valueOf(quantity))); order.setStatus(0); order.setAddress(address); orderMapper.insert(order); return order; } }对应的 SQL 写在 ProductMapper 的注解里：
@Update("UPDATE product SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity}") int deductStock(@Param("id") Long id, @Param("quantity") Integer quantity);这里最关键的是 deductStock 的 WHERE 条件里带了stock >= #{quantity}。数据库的行锁会保证同一时刻只有一个事务能更新这一行，所以不会超卖。返回值为 0 说明影响行数为 0，也就是库存不够，直接抛异常让事务回滚。很多新手先 select 查库存、再 update 扣减，两个操作之间被别人插一脚，库存就错了，一定要改成一条原子 SQL。
@Transactional(rollbackFor = Exception.class) 里 rollbackFor 必须写，因为 Spring 默认只在遇到 RuntimeException 时回滚，而业务里常抛的是自定义 BizException，它可能继承自 Exception，不写 rollbackFor 的话事务不会回滚，库存照样被扣。
4. 限量潮玩集中抢购：防超卖与支付回调的四种写法
4.1 为什么一次性抢购最容易翻车
潮玩交易系统和普通电商最大的区别在「限量」两个字。一款限量 30 体的手办，开售时间一到，几百人同时点购买。一旦遇到这种情况，上一章的原子 SQL 虽然不会超卖，但会有两个新问题。第一，MySQL 行锁把同一行商品的更新串行化，所有请求排队等锁，响应时间会涨到秒级，用户那边表现就是「转圈圈」，然后超时重试。第二，重试会叠加到原来的请求后面，库存没超卖，但数据库连接池被拖垮。
很多人的第一反应是加缓存、加队列，但缓存的第一个坑就是缓存和数据库的数据一致性。我的建议是分两层：数据库扣减作为最终保底方案，必须保留；在它前面加一层 Redis 扣减，让热点商品的库存校验和扣减不再打到 MySQL，把数据库的压力从「每一次请求」降到「每成交一单」。
4.2 数据库原子扣减：保底方案不能丢
上一章写的 deductStock 就是保底方案：UPDATE product SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity}。这一条 SQL 可以应对低并发下的正确性。如果前后端分离的毕设只有几十个人用、答辩时现场演示也就几个人点，那用一个缓存是「成本大于收益」。我的判断标准是：单款商品预估同时在线抢购人数超过 50，就值得上 Redis；毕设演示用原子 SQL 已经足够了。
但注意，保底方案虽然不超卖，却存在「重试风暴」：用户点一次下单，前端有可能因为超时就自动重发。Redis 扣减的另一个作用是挡掉大部分重试流量，让数据库只在真正成交时才被访问。
4.3 Redis + Lua 扣减：把热点商品挡在缓存层
先把商品库存预热到 Redis，key 设计为product:stock:商品id，value 就是剩余库存。扣减用 Lua 脚本来做，保证取数和扣减是原子的：
local key = KEYS[1] local quantity = tonumber(ARGV[1]) local stock = tonumber(redis.call('GET', key)) if not stock then return -1 end if stock < quantity then return 0 end redis.call('DECRBY', key, quantity) return 1Java 侧的执行代码：
private static final DefaultRedisScript<Long> DEDUCT_SCRIPT = new DefaultRedisScript<>( "local key = KEYS[1] " + "local qty = tonumber(ARGV[1]) " + "local stock = tonumber(redis.call('GET', key)) " + "if not stock then return -1 end " + "if stock < qty then return 0 end " + "redis.call('DECRBY', key, qty) " + "return 1", Long.class); public boolean deductStockCache(Long productId, Integer quantity) { Long result = redisTemplate.execute(DEDUCT_SCRIPT, Collections.singletonList("product:stock:" + productId), quantity.toString()); if (result == null || result == -1L) { log.warn("缓存库存不存在或已过期，productId={}", productId); return false; } if (result == 0L) { log.warn("缓存库存不足，productId={}", productId); return false; } return true; }三个返回值对应三种情况：-1 表示 Redis 里的 key 不存在，可能是没做预热或者预热过期，此时应该直接返回失败而不是去数据库兜底，否则反而会把流量放回数据库；0 表示库存不足，不允许下单；1 表示扣减成功。
预热和回补的细节：Redis 每扣减一次，库存就少一件，但数据库的库存扣减要等下单成功后才执行。如果用户扣减完 Redis 库存后没有完成下单（比如支付失败或取消），需要把 Redis 里的值加回去。我一般做法是订单从「已支付」变「已取消」时，先回补 Redis 库存，再异步回补数据库库存。回补操作一定要做，否则「限量 30 体」最后只卖出去 28 体，剩下 2 体在缓存里丢失了，运营会找上门。
4.4 模拟支付回调：幂等是支付系统的底线
毕设里的支付都是模拟，但模拟也要按真实支付回调的套路来写。前端拿到订单号后调 /api/pay/mock，后端生成一个支付单并等待 3 到 5 秒模拟银行处理，然后回调修改订单状态。常见的错误是：用户多点了几次支付，订单状态被反反复复改，甚至同一笔支付回调被处理两次，金额重复入账。
解决办法是在订单表上加一个 pay_id 唯一索引，或单独建一张 payment 表，处理回调时先 insert 再 update 订单状态。支付回调的处理器必须是幂等的：同一个回调事件，处理一次和处理十次，结果都相同。最简单的方式是在回调里先查订单状态，只有「待支付」才允许改成「已支付」，否则直接返回成功。再用一张 payment_callback 表记录每个回调的唯一标识（比如支付渠道的 transaction_id），唯一索引兜底，重复回调直接忽略。
5. 论文写作与答辩避坑：四类最常见的翻车记录
5.1 现象：项目启动报错，SpringBoot 版本太高
现象：把 pom.xml 里 SpringBoot 版本改成 3.2.x 后，项目启动直接报 ClassNotFoundException: javax.servlet.Filter，或者 MyBatis-Plus 的 BaseMapper 方法全部报错。
原因：SpringBoot 3.x 从 JavaEE 的 javax 命名空间迁移到了 Jakarta EE 的 jakarta 命名空间，所有 javax.servlet、javax.validation 都变成了 jakarta.servlet、jakarta.validation。代码和依赖里如果还在引 javax，运行时就会找不到类。同时 MyBatis-Plus 官方适配 SpringBoot 3.x 的版本要到 3.5.3 之后才稳定，老版本一启动就翻车。
解决：毕设直接把 SpringBoot 锁在 2.7.18，Java 用 8 或 11，MyBatis-Plus 用 3.5.5。如果老师指定必须用 3.x，那 pom 里的 starter 全部换成 jakarta 兼容版本，并把代码里的 javax.servlet 依赖手动替换为 jakarta.servlet-api。网上大量教程只说前半部分，卡在启动阶段非常正常，这不是你代码的问题，是版本矩阵的问题。
5.2 现象：前端 Vue 打包后放进 SpringBoot 静态目录，刷新页面就 404
现象：npm run build 生成的 dist 目录复制到 src/main/resources/static 下，启动后访问首页能打开，但点击「订单详情」等路由后刷新，直接 404。后端接口 /api 下都正常，只有前端路由刷新挂。
原因：前端用了 Vue Router 的 history 模式，地址栏里是真实的路径比如 /order/detail/1，但后端没有这个路径对应的 controller。刷新时后端找不到路由，就按 404 处理。
解决：加一个过滤器，把不是 /api、不是 /uploads、不带文件后缀的请求全部转发到 index.html。我常用的写法：
@Component public class VueHistoryFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; String uri = req.getRequestURI(); if (uri.startsWith("/api") || uri.startsWith("/uploads") || uri.contains(".")) { chain.doFilter(request, response); return; } request.getRequestDispatcher("/index.html").forward(request, response); } }逻辑说明：uri.contains(".") 是为了过滤 js/css/图片等静态资源，它们必须走真实文件；/api 和 /uploads 分别给后端接口和上传文件让路；其余路径全部转发到 index.html，交回前端路由处理。这个 Filter 在本地联调和部署到 Linux 上都有效，是处理 history 模式最省事的方式。
5.3 现象：论文查重一片红，删了又怕没字数
现象：把「系统采用 SpringBoot 框架，使用 MyBatis 作为持久层框架」这类描述性文字复制到论文里，查重报告上一大片红色，改来改去字数越来越少。
原因：这类句子是全网所有同类毕设的公共模板——搜「基于 SpringBoot 的图书借阅系统」「商品管理系统」，翻十篇就能撞上同一句话。你没有错，错在全世界的同学都写过一样的话。
解决：三个办法。第一，功能性的描述不写长句，改成表格：一列模块名、一列功能、一列对应接口路径，既清晰又不容易被判重。第二，数据库设计部分全部用字段表和 SQL 建表语句，这部分属于规范描述，查重占比极低。第三，用「自己项目的真实细节」替换通用描述：不要写「本系统采用 Redis 缓存热点数据」，而是写「本系统对限量商品使用 Redis 的 String 结构缓存库存，key 设计为 product:stock:商品id，扣减通过 Lua 脚本保证原子性，实测单次扣减耗时约 0.3ms」。带数字和具体设计的句子，查重很难命中。
5.4 现象：答辩时被追问「事务怎么保证」「并发多少」答不上
现象：PPT 上放着登录、商品管理、订单管理几张截图，讲完 CRUD 后老师说「您这个系统如果被几十个人同时下单，库存怎么保证不出错」，当场卡住。
原因：只做了增删改查，没有把任何一处技术难点落到「设计亮点」。答辩老师的问题永远比演示功能高一层，他不在乎你会不会 new 一个 Controller，而是想知道你有没有考虑过数据一致性、并发、安全这些工程问题。
解决：论文里要有专门的一节写「系统关键问题与解决方案」，把第四章的防超卖内容提炼成三句话：原子 SQL 作为保底、Redis + Lua 扣减缓存库存、模拟支付回调幂等。答辩时被问并发问题，先承认「毕设环境没做大规模压测」，再补一句「但库存扣减在设计和实现时做了原子性保障」，然后把那条 UPDATE SQL 背出来。只要你能把一条 SQL 的行锁原理讲清楚，老师基本不会继续深挖。
6. 上线前最后一轮验证，以及我养成的一个习惯
6.1 最少要过的验证清单
项目临近提交时，按下面这个表过一遍，比反复改前端样式有价值：
| 验证项 | 检查内容 | 常见失败点 |
|---|---|---|
| 功能链路 | 注册->登录->上架->下单->支付->发货->签收 | 订单状态跳不过去 |
| 权限安全 | 买家能否访问卖家接口、能否改别人的订单 | 拦截器只配了登录，没配角色 |
| 数据一致性 | 扣库存后取消订单，库存是否回补 | 只扣不回补 |
| 部署复现 | 服务器上 jar 包能否直接启动 | 数据库连接、上传目录权限 |
6.2 我的教训：把配置和版本号当成代码一样管
我做过不止一个 SpringBoot 项目，最惨的一次是重装系统后代码在 Git 上有，但 application.yml 里数据库密码、上传目录全部丢失，重新配的时候发现 MyBatis-Plus 版本也和原来对不上，折腾了两天。从那以后我就养成了一个习惯：项目根目录建一个 docs 文件夹，里面放三样东西——application-local.yml 的样例（密码写成占位符）、数据库建表 SQL 脚本、README 里写清 JDK 和 SpringBoot 版本号。这三样东西跟着代码一起提交，换电脑、换环境、答辩前突击部署都不会翻车。
如果你正在做这个 SpringBoot 的潮玩交易系统，我建议你也把版本号锁死在文本里，别用「最新版」，任何一次依赖版本升级都可能带来无意义的排错时间。项目做到能跑通全链路不是终点，能把防超卖、幂等、状态机这些点讲出自己的实现细节，才是答辩时真正有底气的部分。毕竟毕业设计不是做一个完美产品，而是证明你理解了一个系统从拆解到落地的全过程。希望上面的路径和踩坑能帮到你，祝你顺利交出这份 SpringBoot 系统设计与实现论文。
本文还有配套的精品资源，点击获取
