1. 项目概述与需求拆解
1.1 物品捎带平台到底解决什么问题
做毕业设计或者练手项目，最怕的就是选一个自己都说不清业务逻辑的题目。物品捎带平台这个题目，乍一看就是“帮人带东西”，但真把它拆开来看，你会发现它其实是一个典型的“C2C 即时配送 + 信息撮合”类业务，和市面上的跑腿、同城闪送、顺路带物产品属于同一套逻辑，只是运营模式更轻、更偏平台化。
核心业务一句话就能讲清楚：有用户需要把物品从 A 地送到 B 地，但他不想专门叫跑腿、不想付高价运费，于是发布一条捎带需求；另一个用户或者兼职骑手恰好有出行路线、有余力，就接下这个单，顺路把东西带过去，平台从中收取信息费或者抽成。
这个业务模式决定了系统必须包含三个核心角色：发布需求的用户（发件人）、承接订单的用户（捎带人）、平台管理方（管理员）。发件人关心的是“需求能不能快速被接单、物品怎么交接、价格是否透明”，捎带人关心的是“顺路程度、报酬是否合适、发件人是否靠谱”，管理员关心的则是“订单全流程是否可追踪、用户之间有没有纠纷、平台收了多少钱”。
1.2 这类项目的核心痛点在哪
按照我做过同类项目的经验，物品捎带平台这类题目最容易踩的坑有三个：
第一个坑，是把需求当成“普通 CRUD”来做。很多同学一看到 Spring Boot 就默认这项目就是写几个增删改查接口，把用户、订单、支付、评价这几张表一建完就交差了。但评阅老师或者面试官真正关心的是你有没有把业务闭环做通：发布单之后怎么保证订单状态不乱、两个人同时抢一个单怎么处理、订单完成后资金怎么结算、用户投诉了怎么走仲裁。这些才是平台类项目的灵魂，也是拉开分数差距的地方。
第二个坑，是把并发问题搞得太复杂或者完全忽略。物品捎带平台天然存在“多个人抢同一个订单”的场景，如果你不用并发控制，两个捎带人同时点了接单，订单却只允许一个人接走，那另外一个人看到的还是“可接单”状态，就会出现超接问题。这属于线程安全场景，Spring Boot 单体虽然好写，但该上锁的地方必须上锁。
第三个坑，是没有把“状态机”设计好。订单不是一张表里加个 status 字段就完事，而是要从“待接单 -> 已接单 -> 配送中 -> 已完成 -> 已评价”这条链路完整串起来。哪怕是一个毕业设计，你也要让评审一眼看出你懂得用状态去驱动业务流程，而不是靠到处写 if else 拼逻辑。
清楚了这三点，下面技术方案的选型就有据可依了。
2. 技术选型与整体架构设计
2.1 为什么核心框架选 Spring Boot
这个项目既然标题直接点名了 Spring Boot，那核心框架就没有悬念，但你要清楚 Spring Boot 在这个项目里到底承担了什么角色。
Spring Boot 最大的价值是让 Java 后端开发从繁琐的 XML 配置中解脱出来，通过自动配置和约定优于配置的原则，快速搭建一个可运行的 Web 服务。以物品捎带平台为例，你需要解决依赖注入（用户的 Service 调 Mapper 要注入）、Web 接口暴露（前端要调后端 REST API）、事务管理（接单操作必须保证状态变更和订单绑定在同一事务里）、参数校验（发布物品信息必然要做非空、长度、类型校验）等基础问题，Spring Boot 都能开箱即用。
我个人在实际项目中更看重它三点：一是起步快，项目骨架几分钟就能拉起来；二是生态好，要接 Redis 有 starter，要接 MyBatis 有 starter，要接支付回调有现成的 HTTP 处理方案；三是排错容易，因为它默认的日志体系和异常处理机制比较完善，对于学习者和毕设场景，遇到问题能在网上找到大量同款经验。
版本选择这块，建议不要盲目追求新版本。Spring Boot 3.x 确实新，但它要求 JDK 17 起步，很多学校的实验环境还是 JDK 8，而且部分老教程里的代码在 3.x 上直接报错。如果你打算用到 2.x 时代最成熟的生态组合（JDK 8 + Spring Boot 2.7.x + MyBatis + MySQL），踩坑成本会小很多。当然，如果设备上已经装了 JDK 17，用最新的 Spring Boot 3.2 也是可以的，只是要注意 javax 命名空间变成了 jakarta，这个迁移细节在 5.2 节我会专门讲。
2.2 整体架构怎么分层
我建议采用经典的前后端分离结构，后端是 Spring Boot 单体应用，前端用 Vue 3 + Element Plus 构建管理后台和用户端页面，数据库用 MySQL，缓存用 Redis。
后端内部继续分层，这是你在代码里必须体现的规范性：
- Controller 层：只负责接收参数、调用 Service、包装返回结果，不在里面写业务逻辑。
- Service 层：承载核心业务规则，比如发布订单的校验、接单时的锁处理、状态流转限制。
- Dao/Mapper 层：负责和数据库交互，只做数据读写，不掺入业务判断。
- Entity/DTO 层：实体类对应数据库表结构，DTO 专门用来做接口出入参封装。
这套分层方案在毕业设计里几乎是标准答案，它既能让代码结构一眼看懂，也方便你逐个模块测试。当年我见过不少同学把业务逻辑全堆在 Controller 里，一个方法写了两三百行，后来连自己回头改需求都找不到地方，这种反面教材务必避免。
2.3 数据库设计思路
数据库设计是这类平台项目的重点，你不需要设计得像淘宝那么复杂，但核心业务表必须齐全且符合实际运营逻辑。我设计过一版基本可以满足毕设和演示需求的表结构，列出来供参考：
用户表（user）：用户 ID、昵称、手机号、密码（加密存储）、头像 URL、注册时间、用户类型（普通用户/捎带人/管理员）、信用分。
物品信息表（goods）：物品 ID、所属订单 ID、物品名称、物品类型（文件/食品/电子产品/其他）、物品描述、物品图片、重量等级、保价金额（可选）。
订单表（order）：订单 ID、发布人 ID、捎带人 ID、物品 ID、起点/终点位置、起终点经纬度、期望送达时间、订单状态（待接单/已接单/配送中/已完成/已取消/争议中）、运费金额、平台抽成金额、创建时间、完成时间。
同时还应该有一张订单状态变更日志表（order_log），用来记录每个订单从创建到完成每一步的状态变更。这张表很关键，它不仅能帮你排查问题，也是答辩时展示你考虑周全的有力证据。
在此基础上还可以扩展三张表：评价表（评价人 ID、被评价人 ID、订单 ID、评分、内容）、支付流水表（订单 ID、支付金额、支付方式、支付状态、第三方回调凭证）、反馈投诉表（投诉人、被投诉人、订单 ID、投诉内容、处理状态）。这样整个业务闭环就完整了。
关于经纬度字段，建议用 DECIMAL(10, 6) 存储，不要用 DOUBLE，因为 DOUBLE 在计算距离时容易出现精度抖动，而且 DECIMAL 在数据库里的可读性更好。起终点位置除了存文本地址，最好再单独存一份经纬度，方便以后按距离排序筛选“顺路单”。
2.4 Redis 在项目里能发挥多大作用
很多毕业设计用了 Redis 但只是用来存个 token，说实话有点浪费。在物品捎带平台这个场景里，Redis 能做的事情很多：
热点数据缓存：首页的捎带需求列表、订单详情、用户信息这些读多写少的数据，可以缓存到 Redis，降低数据库压力。
分布式锁：抢单操作是并发最高的场景，用 Redis 的SETNX实现一把简单的分布式锁，保证同一笔订单只能被一个人接走。
会话管理：因为做了前后端分离，Session 不再适用于简单场景，用 Redis 存登录 token 是很常见的方案。
但我提醒你一点，如果用的是 Spring Boot 2.7 集成 Redis，连接池依赖需要手动引入，网上很多资料没提这点，启动后会报redis.clients.jedis.JedisPoolConfig相关的错误。这个坑后面 5.4 节我会再展开。
3. 核心模块功能设计与实现
3.1 用户模块：注册登录与权限控制
用户模块虽然基础，但安全方面还是要做到位。密码存储推荐使用 BCrypt 加密（Spring Security 自带，或者单独引入spring-security-crypto依赖），绝对不要明文存库。这是我见过很多项目栽过的跟头——答辩时老师打开数据库看到一串明码，基本就是一个致命印象分。
用户登录后签发 Token（JWT），后续请求在请求头里带 Token，后端通过拦截器或者 Spring Security 过滤器链校验身份。JWT 的好处是无需在服务端维护 Session，天然适合前后端分离架构。
权限控制方面，如果是轻量级方案，定义一个拦截器校验当前用户角色是否匹配；如果想做得更正规，可以引入 Spring Security 或者 Sa-Token。但说实话，毕设项目如果时间紧张，用拦截器 + 自定义注解的方式就足够了，过度引入框架反而增加理解成本。
我推荐一个基础组合：Spring Boot + JWT + HandlerInterceptor。这个方案的代码量可控，应对答辩讲解也绰绰有余，而且你还能把自动装配和拦截器注册的原理讲清楚，面试官会觉得你是真懂。
3.2 订单模块：状态机设计是重中之重
订单模块是整个平台的核心，它的状态流转直接决定了系统好不好用、稳不稳定。
我先定义一个基础状态集合：
- 待接单（0）：用户发布需求成功后进入此状态。
- 已接单（1）：捎带人接单成功后进入此状态。
- 配送中（2）：捎带人点击“开始配送”后进入此状态，表示物品已经在路上了。
- 已完成（3）：捎带人点击“确认送达”，且发件人没有发起争议，订单正常完结。
- 已取消（4）：发件人在待接单状态下取消订单。
- 争议中（5）：任意一方对订单发起投诉后进入此状态，管理员介入处理。
有了状态定义，还要限制状态之间的合法流转。比如：待接单只能流向已接单或已取消；已接单只能流向配送中；配送中只能流向已完成或争议中。这不是靠写 if else 硬编码，而是用一个状态机逻辑类统一控制，这样即使以后要扩展状态也很方便。
举个代码层面的例子，定义操作枚举和状态映射表：
public enum OrderStatus { PENDING(0, "待接单"), ACCEPTED(1, "已接单"), DELIVERING(2, "配送中"), COMPLETED(3, "已完成"), CANCELLED(4, "已取消"), DISPUTED(5, "争议中"); private final int code; private final String desc; // 构造方法和 getter 省略 }然后再做一个状态流转校验器：
public class OrderStateMachine { private static final Map<Integer, Set<Integer>> TRANSITIONS = new HashMap<>(); static { TRANSITIONS.put(OrderStatus.PENDING.getCode(), Set.of(OrderStatus.ACCEPTED.getCode(), OrderStatus.CANCELLED.getCode())); TRANSITIONS.put(OrderStatus.ACCEPTED.getCode(), Set.of(OrderStatus.DELIVERING.getCode(), OrderStatus.CANCELLED.getCode())); TRANSITIONS.put(OrderStatus.DELIVERING.getCode(), Set.of(OrderStatus.COMPLETED.getCode(), OrderStatus.DISPUTED.getCode())); TRANSITIONS.put(OrderStatus.DISPUTED.getCode(), Set.of(OrderStatus.COMPLETED.getCode(), OrderStatus.CANCELLED.getCode())); } public static boolean canTransition(int current, int target) { Set<Integer> allowed = TRANSITIONS.get(current); return allowed != null && allowed.contains(target); } }这样设计之后，Service 层的每个状态变更操作前都先过一遍状态机校验，就算代码里有并发漏洞，也不至于把订单状态搞成非法组合。
3.3 抢单场景：并发控制才是真正的技术点
抢单是物品捎带平台和高并发场景最接近的模块。需求发布之后，多个用户可能同时看到订单并点击接单，这时候后端必须保证：一个订单只能被一个捎带人接走。
最简单的办法是把接单操作包在一个事务里执行：
@Transactional public void acceptOrder(Long orderId, Long userId) { // 1. 查询订单 Order order = orderMapper.selectById(orderId); if (order == null || order.getStatus() != OrderStatus.PENDING.getCode()) { throw new BusinessException("订单不存在或已被接走"); } // 2. 校验用户身份 // 3. 更新订单状态 int rows = orderMapper.compareAndSetStatus(orderId, OrderStatus.PENDING.getCode(), OrderStatus.ACCEPTED.getCode(), userId); if (rows == 0) { throw new BusinessException("手慢了，订单已被接走"); } }重点是第三步用的 SQL 不是简单的update order set status = 1 where id = ?，而是带条件更新：
UPDATE `order` SET status = 1, acceptor_id = #{userId} WHERE id = #{orderId} AND status = 0这样利用数据库行锁和原子更新，天然避免并发覆盖，比自己写 Java 层synchronized要可靠得多，也更容易解释给评审听。
如果项目里已经引入了 Redis，还可以再加一层分布式锁做双保险，但核心还是数据库的乐观更新语句。说句实在话，毕设级别把 database-level 的 compare-and-set 理解到位，已经比大部分同学强了。
3.4 消息通知：让状态变化时刻可感知
用户发布需求之后，要能收到“订单被接单”“物品已送达”等通知，才像个完整平台。消息通知模块可以做成两种方式：
WebSocket 实时推送：用户停留在订单详情页时，后端通过 WebSocket 推送订单状态变化给前端，刷新页面上的最新进度。
短信/站内信：订单完成、审核结果等事件，写一条通知记录到数据库，用户在消息中心查看；如果需要更真实，可以接阿里云短信接口。
我建议先实现站内信，因为它的代码结构最简单，还能给系统增加一个“消息中心”页面，让功能看起来更完整。WebSocket 属于加分项，有时间再补。
站内信表结构很简单：ID、接收人 ID、标题、内容、类型（系统通知/订单通知）、是否已读、创建时间。发件人接单成功后，在 Service 里同步插入一条消息记录即可。这里要注意的是，消息写入和订单状态更新应该在同一个事务里，否则可能出现订单状态改了但通知丢了，用户会觉得莫名其妙。
3.5 评价与投诉：信任体系的基础
平台类产品必须有信用体系，评价是信任的基础。我建议在订单完成后 7 天内允许双方互评，超过时限不能再评价。评价表主要存评分（1-5 星）和评价内容，同时要冗余一份被评价人 ID 和订单 ID，方便后续统计用户的平均评分。
投诉流程可以做简化版：用户对订单某个环节不满意，提交投诉记录，订单状态进入“争议中”，管理员在后台看到后，可以查看订单详情和双方留言，最后管理员操作“支持发件人”或“支持捎带人”或者“双方无责取消”，订单流转到对应终态。这个功能不需要做得很复杂，但能把管理员的参与感体现出来，对答辩很有价值。
我遇到过不少同学，做评价功能只是写死“订单完成后自动五星好评”，这属于纯粹走过场，对你的项目是扣分项。真实一点，加上评分、内容、时间限制，这套逻辑才立得住。
4. 实操过程与核心环节实现
4.1 项目初始化和依赖配置
用 IDEA 新建一个 Spring Boot 工程，Group 填com.example，Artifact 填carry-platform，语言选 Java，打包方式选 Jar，Java 版本根据你本机环境选 8 或 17。
核心依赖如下（以 Spring Boot 2.7.x 为例）：
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>com.auth0</groupId> <artifactId>java-jwt</artifactId> <version>3.19.2</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>然后配置 application.yml：
server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/carry_platform?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password redis: host: localhost port: 6379 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.carryplatform.entity configuration: map-underscore-to-camel-case: true这里有个重要的配置项：map-underscore-to-camel-case: true。它能把数据库里的acceptor_id自动映射成实体类的acceptorId，省去手动写一堆 resultMap 的麻烦。这个配置千万不要漏，否则你写 SQL 的时候会发现返回的对象一堆字段是 null，排查非常浪费时间。
4.2 发布捎带需求的完整链路
发布需求是用户端最核心的操作，我来完整走一遍这个流程，代码逻辑顺序必须严格。
第一步，前端提交表单，包含物品名称、物品类型、起点、终点、期望送达时间、运费报价、备注信息。
第二步，后端 Controller 接收参数并做基础校验，比如起点终点不能为空、运费报价必须大于 0、物品描述不能超过 500 字。这部分校验直接用 JSR 303 注解搞定，不用手写 if。
第三步，Service 层组装订单对象。这里要注意一个业务细节：发布需求的同时，一定要创建一条物品信息记录，两者存在一对一的关联关系。也就是说，一次发布操作涉及两张表的写入，必须放在同一个事务里。
第四步，调用 Mapper 分别插入数据，插入完成后清理这条需求在 Redis 中的列表缓存，让下次拉取首页需求时能拿到最新数据。
第五步，返回“发布成功”响应，前端将用户跳转到订单详情页或“我发布的”列表。
代码上，Service 层的核心方法大概长这样：
@Transactional(rollbackFor = Exception.class) public Long publishOrder(PublishOrderDTO dto, Long userId) { // 1. 参数校验已在 Controller 完成，这里主要做业务校验 Goods goods = new Goods(); goods.setName(dto.getGoodsName()); goods.setType(dto.getGoodsType()); goods.setDescription(dto.getDescription()); goods.setWeightLevel(dto.getWeightLevel()); goods.setImageUrl(dto.getImageUrl()); goodsMapper.insert(goods); Order order = new Order(); order.setPublisherId(userId); order.setGoodsId(goods.getId()); order.setStartLocation(dto.getStartLocation()); order.setEndLocation(dto.getEndLocation()); order.setStartLatitude(dto.getStartLatitude()); order.setEndLatitude(dto.getEndLatitude()); order.setExpectedTime(dto.getExpectedTime()); order.setAmount(dto.getAmount()); order.setStatus(OrderStatus.PENDING.getCode()); orderMapper.insert(order); // 清理列表缓存，让首页及时展示新单 redisTemplate.delete("order:pending:list"); return order.getId(); }注意@Transactional(rollbackFor = Exception.class)这个写法，默认情况下 Spring 只在遇到 RuntimeException 时才回滚，如果业务代码抛的是受检异常，事务不会自动回滚。养成写 rollbackFor 的习惯，能避免很多奇奇怪怪的数据不一致问题。
4.3 接单模块和 Redis 分布式锁的落地
接单模块虽然代码量不大，却是整个项目最能体现技术水平的地方。
我先给出基于 Redis 分布式锁的完整代码，再解释每一行的意义：
public Boolean acceptOrder(Long orderId, Long userId) { String lockKey = "order:lock:" + orderId; String lockValue = UUID.randomUUID().toString(); Boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, lockValue, Duration.ofSeconds(10)); if (Boolean.FALSE.equals(locked)) { throw new BusinessException("手慢了，订单已被接走"); } try { return doAcceptOrder(orderId, userId); } finally { // 释放锁时校验唯一标识，防止误删别人的锁 String currentValue = redisTemplate.opsForValue().get(lockKey); if (lockValue.equals(currentValue)) { redisTemplate.delete(lockKey); } } }setIfAbsent是 Redis 实现分布式锁的核心方法，它保证当 key 不存在时才设置成功，并且要带上过期时间，免得程序崩溃后锁一直不释放。释放锁之前先比对 value，是为了防止一个线程的锁超时自动过期后，另一个线程又创建了同 key 的新锁，这时候如果直接 delete，就会把别人的锁删掉。这是分布式锁的经典坑，我在项目里踩过一次之后，再也不敢直接delete(lockKey)。
不过我还是建议把这个逻辑和数据库的 CAS 更新配合使用。Redis 锁只是降低冲突概率的挡板，数据库UPDATE ... WHERE status = ?才是真正兜底的并发防线。分布式锁如果挂掉了，数据库还能靠行锁兜住；数据库如果有并发问题，Redis 锁也能在前置拦截一层。
4.4 管理员后台：订单查询与数据看板
管理员后台的核心功能是订单管理：按状态、时间、关键字筛选订单，查看订单详情（包括物品信息、双方用户信息、状态变更日志），处理争议订单。
订单列表查询要配合分页实现，这里我用的是 PageHelper 分页插件，配置非常简单：
<dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper-spring-boot-starter</artifactId> <version>1.4.7</version> </dependency>在 Service 里只要先调用PageHelper.startPage(pageNum, pageSize)，紧接着执行 Mapper 查询，返回结果就是分页后的列表。注意一点，startPage之后必须紧跟第一条 SQL 查询语句，中间不要穿插其他数据库操作，否则分页会失效。
建议增加一个简单的数据看板，展示总订单数、今日新增订单数、待接单数量、用户总数、平台累计抽成金额。这些统计信息可以用几条聚合 SQL 在管理后台首页渲染出来，让项目在演示时更有说服力。虽然实现不复杂，但会让整个系统显得非常完整。
4.5 支付环节如何做到可信
支付环节在毕业设计里不需要真的接入微信/支付宝支付，但必须把支付流水和状态体现出来。我采用的是模拟支付方式：用户在订单完成后点击“确认支付”，后端生成一条支付流水记录，状态置为“已支付”，并把订单标记为“已完成”。
如果有余力，可以接一个第三方支付沙箱环境，比如支付宝沙箱，配合回调接口。但老实说，支付的完整闭环涉及异步回调、签名验证、幂等处理，在毕设的时间预算里非常占精力。我更建议把重点放在支付流水表设计上：记录订单 ID、金额、支付方式、支付状态、支付时间、回调凭证，面试时能说清这笔钱从用户到平台再到捎带人手里的流转逻辑就够了。
真正想加分，可以设计一个简单的资金结算功能：订单完成后，平台按比例抽成，剩余金额进入捎带人的“可提现余额”，捎带人申请提现，管理员审核后模拟打款。这会把业务从单纯的信息撮合升级到资金流转，整体完整度提升一个档次。
5. 常见问题与排查技巧实录
5.1 版本太高带来的连锁反应
Spring Boot 版本升级不是小事，我在一个项目里从 2.7 升到 3.x 时，发现大量依赖需要同步升级，过程相当折腾。做毕设项目的同学，除非你已经熟悉新版本生态，否则我强烈建议用 2.7.x 搭配 JDK 8，这是目前资料最多、踩坑成本最低的组合。
如果你确实想用 Spring Boot 3.x，一定要记住最核心的变更：
- 包名从
javax.*变成jakarta.*，涉及HttpServletRequest、Validation等大量类。 - Java 版本要求 17 及以上。
- MyBatis 相关的 starter 需要升级适配版本。
- 部分 Redis 客户端配置方式发生变化。
遇到启动报错，第一件事先确认是版本不匹配还是代码不兼容。比如ClassNotFoundException: javax.servlet.Filter这种报错，基本就是 Spring Boot 3.x 项目里还在用javax导致的。
5.2 JDK 版本和 Maven 依赖冲突
电脑上同时装了 JDK 8 和 JDK 17 的同学，经常会遇到 IDEA 里项目编译报错“java: 无效的源发行版 17”。这个错误说明 IDEA 当前编译级别不对。
解决方法有三种，按优先级排序：
第一，点开 IDEA 的 Project Structure（快捷键 Ctrl+Alt+Shift+S），确认 Project SDK 和 Project language level 一致。
第二，确认 Maven 的 Java 版本设置。在 pom.xml 里显式配置：
<properties> <java.version>1.8</java.version> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> </properties>第三，在 IDEA Settings 里检查 Java Compiler 的 Target bytecode version 是否设成了 17。
这三步做完，基本能解决绝大多数“环境没问题但编译报错”的情况。
5.3 Spring Boot 循环依赖的经典陷阱
循环依赖在 Spring Boot 2.6 及以上版本默认被禁止，一旦代码里 A 依赖 B、B 又依赖 A，启动时就会报错。这在电商类的订单、用户、优惠券这种互相引用的场景里非常常见。
我遇到过一个实际案例：订单 Service 需要调用用户 Service 查信用分，用户 Service 又需要调用订单 Service 查交易次数，两个类互相注入，项目怎么也启动不了。
排查思路很简单：先看启动日志里的循环依赖提示，找到是哪两个 Bean 互相引用。
解决办法我推荐两种，按优先级排列：
第一，重新设计职责边界。把公共逻辑抽到一个独立的 Service 或者工具类里，谁都不依赖谁，这是最彻底的方案。
第二，使用@Lazy注解延迟加载。在其中一个注入点加@Lazy，让 Spring 先创建代理对象，等真正调用时才初始化完整 Bean。这虽然能解决问题，但本质上是在掩盖设计问题，不建议作为首选。
5.4 Redis 连接池缺失报错
如果你的项目是 Spring Boot 2.7 + spring-boot-starter-data-redis，默认底层用的是 Lettuce 客户端，本身不带连接池。当你尝试在配置里设置连接池参数时，如果没引入commons-pool2依赖，启动时会直接报ClassNotFoundException: org.apache.commons.pool2.impl.GenericObjectPool。
解决方法是在 pom.xml 里补充：
<dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-pool2</artifactId> </dependency>这个问题在整合 Redis 时非常常见，网上的配置教程大多默认你已经引入了这个依赖，结果自己搭环境时少走一步就卡住。
5.5 MyBatis 报错和字段映射问题
MyBatis 集成里最容易出现的报错是Invalid bound statement (not found)，通常是因为 Mapper 接口和 XML 文件没有正确对应。排查顺序：
- 检查 XML 文件的 namespace 是不是 Mapper 接口的全限定名。
- 检查接口方法名和 XML 里的
<select>/<update>id 是否一致。 - 检查 mapper-locations 路径是否正确。
另一个高频问题就是我在 4.1 节提到的下划线驼峰映射。如果没有开启map-underscore-to-camel-case，数据库的publisher_id在实体类里映射不到publisherId，查出来的对象就缺字段。打开 MyBatis 日志（logging.level.com.example.carryplatform.mapper=debug），看到 SQL 有输出但 Java 对象里的属性为 null，基本就是映射配置的问题。
5.6 上传下载大文件的处理
物品捎带平台涉及用户上传物品图片，虽然大部分场景图片体积不大，但如果你在做一个更完整的版本，需要处理大文件上传下载，一定要避开一个常见坑：直接使用 Spring 的MultipartFile一次性读入内存，超过内存阈值会抛出异常。
推荐改成流式处理，把文件切块写入磁盘或者云存储。在 Spring Boot 中可以通过配置文件调整 Spring MVC 的上传限制：
spring: servlet: multipart: max-file-size: 20MB max-request-size: 50MB对于超过 50MB 的文件，那就涉及分片上传方案，需要前端把文件切开、分批上传、后端合并，这属于另一个复杂度级别，毕设不推荐重写。
5.7 事务失效的几种情况
事务注解失效是 Spring 面试经典题，也是实际项目里最容易踩的坑。用@Transactional时记住以下几条：
- 方法必须是 public，且必须通过代理对象调用，同类内部调用（比如同一个类里 A 方法调 B 方法）不会触发事务。
- 默认只回滚 RuntimeException，需要回滚受检异常时要写
rollbackFor = Exception.class。 - 数据库表引擎必须是 InnoDB，MyISAM 不支持事务。
- 异常被 try-catch 吃掉不会回滚，除非手动
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。
这四条每一条我都踩过，特别是第一条“同类内部调用导致事务失效”，代码明明逻辑没问题，数据就是写了一半，排查了很久才发现是 AOP 代理的问题。
6. 写在最后
物品捎带平台这个题目，本质上是一个标准的“信息撮合 + 订单流转 + 信用评价”业务系统，用 Spring Boot 做后端是再合适不过的选择。它能全方位锻炼你的事务能力、并发控制、状态机设计、缓存使用以及前后端联调能力，这些正好是 Java 后端岗位面试的高频考点。
我在做同类项目时最大的体会是：不要在单个功能上追求花哨，而是要把核心业务链路跑顺畅。与其花大量时间做一个面部识别登录，不如把订单状态机、抢单并发、资金流水、评价体系这几个真正决定平台质量的模块做扎实。评阅老师看重的是业务完整度，面试官看重的是你对自己代码的解释深度。
如果你准备自己动手做一遍，我的建议是分三步走：先根据 2.3 节的数据表结构把库建好，再按照状态机逻辑把后端核心接口（发布、接单、完成、评价）全部打通，最后再去补充管理后台和消息通知这类锦上添花的功能。按这个顺序推进，即使中途遇到问题，也不会出现“做了一半发现核心逻辑要推翻”的窘境。
