Spring Boot快递管理系统开发实战：从数据库设计到答辩指南

1. 为什么选“基于Spring Boot的快递管理系统”做毕业设计：这个题没有看起来那么简单

先说结论：快递管理系统这类题目，在一堆“学生管理系统”“图书管理系统”里看起来平平无奇，但它反而是非常稳妥、性价比很高的毕设选题。我在准备这个题目的时候，最初的想法很简单——自己平时网购多，快递追踪用得多，但真正把一个快递从“下单寄件”到“用户签收”的全流程拆成系统功能，工作量并没有想象中那么小。

很多同学选毕设题目容易走两个极端：要么选一个太简单的（比如纯增删改查的某某信息管理），写到中期发现没内容可写，论文单薄得拿不出手；要么选一个技术太前沿的（比如基于微服务+容器化的什么系统），结果自己从零开始搭框架就耗掉一个多月。快递管理系统恰恰落在中间：核心业务链路长、角色多、状态变化复杂，但每个单独的技术点又都是主流Java岗面试会问的东西，做起来不虚。

更实际的一点是：Spring Boot 是这个领域的事实标准。你选了这个题目，就意味着你只需专注于业务逻辑，不需要花大量时间处理配置地狱。而快递业务里天然包含“登录鉴权、下单、接单、轨迹流转、分页列表、统计报表、事务回滚”，几乎覆盖了企业级Java开发最常见的日常操作。这些能力既能写进论文，又能在找工作面试时讲成项目经历，不会白做。

这篇内容我按自己实际做完这个项目后的经验来写，包括一开始怎么设计数据库、哪些环节写代码容易翻车、答辩时老师集中在哪些问题、以及远程调试在最后交付演示时到底怎么用。如果你也在做或者准备做类似题目，可以直接把它当成一份“别人的踩坑总结”。

2. 系统设计阶段：快递业务建模的第一步是分清角色和状态

很多初学者拿到这个题目，第一反应是建表。其实不对，第一步应该先搞清楚：到底有哪几类人会用这个系统，以及快递从产生到结束，中间要经历哪些状态。

2.1 三类核心角色，对应三种完全不同的操作视角

快递管理系统不是简单地把“快递信息”做增删改查。它是给不同角色使用的，不同角色眼睛里的系统完全不一样。

我这个设计里最终划分了三类角色：

• 管理员：负责平台基础数据维护，包括网点管理、快递员账号管理、查看所有订单、查看运营统计报表。
• 快递员：登录后看到分配给自己的取件/派件任务，可以修改任务状态，比如“已取件”“派送中”“已签收”。
• 普通用户（顾客）：登录后可以下单寄快递、查询自己的订单列表、查看物流轨迹、取消未取件的订单。

这里要注意一点：很多初学版本把“用户”只当成一个登录角色，后台不给用户开放任何入口，这会让系统少一半功能。因为快递系统里真正的核心业务——寄件下单与物流轨迹查询，实际上都是用户视角的。如果你删掉用户端操作，整个系统的业务闭环就不成立，论文里也很难从“使用流程”角度画出完整用例图。

2.2 核心状态机：快递状态是怎么一步步走下去的

数据建模里最容易出错的是订单状态。如果你只用一行注释“订单状态有已发货、已签收”，后面写代码一定会逻辑混乱。

我最后整理出的状态流转是这样设计的：

这套状态机被我记在心里后，后面写 Service 层几乎没纠结过。比如“用户取消订单”这个操作，我就直接在代码里判断：只有 status = 0（待取件）时才允许取消失败，否则提示“包裹已揽收，无法取消”。再比如快递员确认签收时，如果当前状态不是“派送中”，就要报错。这一层约束如果不在代码里写死，演示的时候只要状态乱了，后面所有统计报表都跟着错。

每个状态发生变化的同时，我还会往物流轨迹表里插一条记录。这相当于给每个快递加了一条“时间线”。后面管理员想查某个快递的任何历史流转，直接按时间排序查这张表就行。

2.3 数据库表设计：不追求复杂，但别漏关键字段

我的数据库最终落了7张核心表，额外加1张操作日志表。核心表和用途：

用户表 user

• 用户 id、用户名、密码（加盐哈希存储）、手机号、真实姓名、创建时间
• 角色这里我用的是单独的 user_role 字段（admin / courier / user），没有做一张单独的角色表。查权限时非常快。

快递员表 courier

• 独立出来是因为快递员需要一个“所属网点”字段和管理员关联，如果只放在 user 表里，会给查询增加多余的条件。

网点表 branch

• 省份、城市、区县、详细地址、联系电话。派件任务分配和统计报表都依赖网点维度。

快递单表 express_order

• 订单号（唯一索引）、用户id、寄件人信息、收件人信息、物品名称、重量、体积、运费、当前状态、下单时间、签收时间。收件人字段我会保存姓名、电话、完整地址这三项，不能只存一个收件人ID，因为快递很可能不是同一个系统内的注册用户。

物流轨迹表 express_track

• 快递单 id、操作人、操作类型（揽收/派送/签收等）、轨迹描述、经手网点、创建时间。所有状态变化都会往这里插记录。

快递员任务表 courier_task

• 任务类型（取件/派件）、关联快递单号、快递员id、任务状态（待接单/已完成）、创建时间、完成时间。

申诉表 complaint（如果时间充足尽量做）

• 用户可以对异常快递发起申诉，快递员或管理员进行回复。这个小模块在论文里可以作为“扩展功能亮点”来写，工作量不大，但能体现你对业务异常场景的思考。

建表时有一个实用细节值得专门说：金额字段直接用 decimal(10, 2)，不推荐用 float 或 double，不然算运费对账时会出现让你挠头的小数误差；时间字段统一用 datetime，在 Java 里对应 LocalDateTime，不要再用 java.util.Date。刚开始图省事用 Date 的代码到后面前端格式化时会非常痛苦。

3. 技术选型与工程搭建：Spring Boot 版本怎么选、前后端分不分离

如果完全踩着我走过的路来，技术栈建议定为：Spring Boot 2.7.x + MyBatis-Plus + MySQL 5.7或8.0 + Vue 2 + Element UI。为什么不是 3.x？下面我展开说。

3.1 Spring Boot 版本：别盲目追求新版，兼容性才是王道

做毕业设计，稳定性比版本新更重要。我当时搜索发现很多报错帖都是“Spring Boot版本太高导致 xxx 不兼容”，最后把版本定为 2.7.18。理由是：

1. Spring Boot 2.7.x 对 JDK 1.8 的支持非常成熟，而绝大多数学校实验室或个人电脑里默认安装的就是 JDK 1.8。你如果选了 Spring Boot 3.x，就必须用 JDK 17，还得换一套 Jakarta EE 的命名空间，网上很多老教程直接失效。
2. 网上关于 Spring Boot 2.x + MyBatis-Plus + Vue 的组合资料是最多的，遇到问题一搜就有答案。
3. 毕业后去公司面试，问到的还是 Spring Boot 2.7 和新旧对比居多，用 2.7 做开发不会踩“学了用不上”的坑。

Java 8 是块好砖，哪里需要哪里搬。这个选择在答辩时也不会被扣分，老师更关心的是你为什么要做这个选择和踩坑后怎么解决，而不是你用没用最新版。

3.2 MyBatis-Plus 还是原生 MyBatis？我建议直接用 MyBatis-Plus

我带过的几个学弟做毕设时，喜欢纠结这个问题。我的建议非常直接：单表 CRUD 用 MyBatis-Plus，复杂多表查询自己写 XML。

理由很简单，快递系统的订单列表、用户列表、轨迹列表这些基础接口几乎全是单表查询加条件分页，MyBatis-Plus 自带 baseMapper.selectPage() 可以减少大量样板代码。而像“统计各网点订单量”“查询用户所有快递及最新轨迹”这种多表统计，直接自定义 SQL 写在 XML 文件里比 MyBatis-Plus 的 Wrapper 嵌套要清晰得多。

两种能力组合起来，既节省了体力，又展示了 SQL 功底，论文里可以写一句“项目采用 MyBatis-Plus 作为持久层增强框架，通过自定义 SQL 实现复杂报表查询”，这比单纯堆一个技术名词要让人信服得多。

3.3 前后端分离还是服务端渲染？我的结论是一般选分离

如果你的题目页面上写着“springboot Vue 前后端分离”，那你思路可以很清晰了：后台管理系统做成 Vue 前端 + Spring Boot 后端接口，前端用 Axios 请求后端接口，后端所有接口统一返回 Result 对象。

有人担心前后端分离会增加工作量，因为要多写很多接口交互代码。但从毕设角度看，前后端分离反而更容易查错：前端报错看 Network 面板，后端接口直接浏览器访问 URL 测试，问题定位更清晰，不用把模板引擎渲染那套东西绞在一起。

不过要提醒一点：如果你只擅长 Java，对 Vue 完全没接触过，而且距离答辩只剩三周，我建议用 Spring Boot 自带的 Thymeleaf 模板引擎做服务端渲染，核心页面就是快递单管理、用户管理、统计列表这些，没有太多复杂交互。先毕业，再谈做成前后端分离的线上完整项目也来得及。但既然标题里提到了 Vue，那普通情况下还是选择“Spring Boot + Vue”去搭建，企业开发主流，演示效果也好。

3.4 包结构设计：别把代码都堆在一个包下面

我把工程结构设计成了如下形式：

code复制com.example.express
├── controller        // 接口层
├── service           // 业务层
│   └── impl
├── mapper            // 数据访问层（MyBatis-Plus的Mapper）
├── entity            // 数据表对应的实体类
├── dto               // 前端入参/出参对象
├── vo                // 查询结果封装
├── config            // 配置类（跨域、拦截器）
├── common            // 通用返回结果、异常处理、常量
└── utils             // 工具类

这个结构是最经典的分层结构之一。尤其是 dto 和 vo 的拆分，很多初学者忽略掉，把所有字段放在同一个 entity 类里传给前端。这样做后期容易暴露多余字段，或者接口里传入一个根本不存在的参数时很难定位。我的习惯是 entity 负责映射表单字段，dto 负责接收前端参数，vo 负责输出给前端展示，三者各管各家，分得清清楚楚，代码可读性直接上一个档次。

4. 核心业务实现：这五块代码写通了，整个项目就稳了

4.1 用户下单与快递单号生成：不要直接用自增 ID 当单号

用户下了寄件单，系统保存订单并生成一个快递单号。快递单号如果用数据库自增 id 去拼，比如“100001”，长度不稳定还容易被遍历。我采用了“前缀 + 时间戳 + 随机数”的生成策略：

code复制单号格式：EXP + yyyyMMddHHmmss + 4位随机数字
示例：EXP202412201530451837

代码里可以这样写：

java复制public String generateOrderNo() {
    String time = LocalDateTime.now()
            .format(DateTimeFormatter.ofPattern("yyyyMMddHHmmss"));
    int random = (int)((Math.random() * 9 + 1) * 1000);
    return "EXP" + time + random;
}

这个单号在数据库中设唯一索引。如果极端情况下出现重复（概率极低），通过异常捕获重新生成一次即可。这种处理方式的好处是：从单号本身能直接看出下单时间，演示时一眼就能看出数据是活的，而不是手动造出来的假数据。

4.2 下单后的服务层事务处理：订单和轨迹必须一起成功

用户下单后，除了向 express_order 插入一条订单，还要向 express_track 插入一条“已下单，等待快递员取件”的轨迹记录。这两个操作必须在同一个事务里，不能出现“订单插入成功但轨迹记录失败”的情况。

我用 Spring 声明式事务来处理，在 Service 实现类方法上加上注解：

java复制@Transactional(rollbackFor = Exception.class)
public Long createOrder(OrderCreateDTO dto) {
    // 1. 保存快递单（初始状态=0）
    // 2. 保存一条初始物流轨迹
    // 3. 返回订单ID
}

重点解释一下这个 rollbackFor = Exception.class。Spring 默认只在遇到 RuntimeException 时回滚，如果业务里抛的是 Exception（自定义检查异常），不加这个属性就不会自动回滚。很多新手在这里踩坑后，发现代码明明报错了，数据库里却多了条脏数据。所以写 @Transactional 时我始终带上这个属性，一句话的事，能少一次深夜排查。

4.3 快递员端任务分配：一个“待领取”与“已领取”的控制逻辑

快递员登录后看到两类任务：待领取的取件任务和派件任务。为了防止两个快递员同时点击领取同一个任务，我在 courier_task 表上做了一个流程控制。

任务表设计成有 task_status 字段，取值有 0（待领取）和 1（已被领取/已完成）。领取操作时执行更新 SQL：

sql复制UPDATE courier_task 
SET courier_id = #{courierId}, task_status = 1 
WHERE id = #{taskId} AND task_status = 0

这里的关键是 SQL 里加了 task_status = 0 条件。即使两个快递员同时发起请求，数据库行锁也只会让其中一个更新成功，另一个更新 0 行，接口返回“任务已被其他人领取”。这就是典型的“乐观锁思想”。只要把 update 返回的行数作为判断依据，就不需要在代码里手动加分布式锁，学校环境的演示完全够用。

快递物流行业的并发峰值虽然远高于学校 demo，但这个设计思路在企业里同样常见：用数据库条件更新做并发控制，比 synchronized 这种单机锁优雅得多，也是值得写进论文的技术点。

4.4 物流轨迹查询优化：循环里查 SQL 是最容易犯的错

在前端展示“我的快递列表”时，每个订单下面要显示最新的一条路由状态。但如果列表有 20 个订单，你在 for 循环里逐个请求最新轨迹查询接口，数据库会产生 N+1 次查询，性能非常差。

我最后的设计是：先查询订单列表，根据订单 id 集合一次性查出它们各自的最新轨迹。MyBatis 的 <foreach> 遍历，加上行号函数的嵌套查询，就能把批量问题解决。我自己写的 SQL 大致如下：

sql复制SELECT t.* FROM express_track t
INNER JOIN (
    SELECT express_order_id, MAX(id) AS max_id
    FROM express_track
    WHERE express_order_id IN
    <foreach collection="orderIds" item="orderId" open="(" separator="," close=")">
        #{orderId}
    </foreach>
    GROUP BY express_order_id
) latest ON t.id = latest.max_id

这个写法的核心思想是：用 GROUP BY 拿到每个订单的最新一条轨迹 id，再把 express_track 表 join 回这张 id 表，取出完整轨迹内容。这种 SQL 在答辩现场非常容易讲，能体现出“批量查询优化的意识”。比起 for 循环一条一条查，这种写法在数据量大之后差距非常明显。

4.5 统计报表：管理员首页的折线图数据怎么来

管理员要看今日下单量、各网点订单占比、近7天订单趋势这类数据。这部分我建议直接在后端写 SQL 聚合，不要把所有订单取到内存里再逐个 count。那样写出来的代码在演示时数据量小没问题，但论文里的性能分析会被老师质疑。

举个例子，统计近7天每日下单量，我这样写：

java复制@Mapper
public interface ExpressOrderMapper extends BaseMapper<ExpressOrder> {
    List<Map<String, Object>> selectDailyOrderCount(@Param("startDate") String startDate);
}

xml复制<select id="selectDailyOrderCount" resultType="map">
    SELECT DATE(create_time) AS date, COUNT(*) AS count
    FROM express_order
    WHERE create_time >= #{startDate}
    GROUP BY DATE(create_time)
    ORDER BY date
</select>

然后用一个 VO 把查出来的 List<Map> 封装好返回给前端，前端用 ECharts 画折线图。这就是一个“后端算好数据、前端负责展示”的规范做法。如果你项目里需要统计图，这个思路可以直接套。

5. 开发阶段最容易翻车的几个坑：版本、精度、时区、分页

以下这些坑不全是我凭空想出来的，很多来自给其他同学远程调代码时看到的共性问题，按概率排序列出来。

5.1 Spring Boot 版本和 JDK 不匹配导致的启动失败

有一个非常典型的报错是：“UnsupportedClassVersionError: xxx has been compiled by a more recent version of the Java Runtime”。

有次帮一个学弟调代码，发现他的 pom.xml 里 spring-boot-starter-parent 写的是 3.1.5，但本机 JAVA_HOME 指的却是 JDK 1.8。项目刚启动就直接报版本错误。这个问题的本质就是：高版本 Spring Boot 要求高版本 JDK，二者必须匹配。

我的惯例是拿表格列出来：

如果你本机还装了多个 JDK，一定要确认 IDEA 里 Project Structure 的 SDK、Settings 里的 Gradle/JDK、系统环境变量 JAVA_HOME 三者指向一致。很多时候不是代码的问题，是环境不一致。检查这三处只要两分钟，但能少折腾一个晚上。

5.2 金额字段用 double 计算导致对不上账

运费计算规则是：首重 12 元，续重每公斤 5 元。计算代码如果写成 double 乘 double，在某些重量组合下会出现类似 17.000000000000004 这样的值。插入数据库时如果字段是 decimal(10, 2) MySQL 会按四舍五入截断，但如果你在后续代码里拿这个 double 再乘一个折扣系数，误差就可能被放大，最终两笔订单的运费明细和汇总对不上。

我的解决方式是：所有涉及金额的计算入参、出参、实体类字段全部使用 BigDecimal，构造对象时使用 String 构造器，不要使用 BigDecimal.valueOf(0.1) 这种一个参数传入 double 重载。例如重量从 0.1 累加到 0.7 时，用 double 累加后结果会变成一个很长的不可读小数，而用 new BigDecimal("0.1") 就能避免这个问题。另外，接口传给前端时要把 BigDecimal 转成字符串返回，否则传到前端会出现 11.2 变成 11.200000000000001 的问题。

5.3 数据库时区设置问题导致的时间差 8 小时

前后端联调时，前端展示的时间比本地时间少了 8 小时，这个问题非常经典。原因是 MySQL 连接字符串里的 serverTimezone 与数据库时区不一致。

我用的连接串如下：

code复制jdbc:mysql://localhost:3306/express_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true

注意 serverTimezone 写的是 Asia/Shanghai。如果你的 MySQL 版本是 8.x，除了连接串，还要在 MySQL 服务端设置默认时区，我之前习惯在 my.ini 里的 [mysqld] 区加上一行：

code复制default-time-zone = '+08:00'

另外还有一个精度问题：如果你在 MySQL 里用了 datetime 而不是 timestamp，它存储的就是字面时间，不随时区变化。这也是很多人改了连接串还是差 8 小时的原因。后端 LocalDateTime 传给前端时，还要处理好序列化的时区配置，在 application.yml 里配置：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

这样前后端的时间展示就彻底统一了。很多同学时间不对只改数据库连接串，不改 jackson 时区，结果改完照样错，说的就是这个原因。

5.4 MyBatis-Plus 分页不生效，查出来全是全表数据

使用 MyBatis-Plus 写分页查询时，只调用 selectPage() 是不够的，一定要注册分页插件，否则 MyBatis-Plus 发出的 SQL 根本没有 LIMIT 关键字，返回的数据其实是全量数据，只是前端显示成了部分，接口性能也会非常差。

在配置类里加上：

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

这里用 DbType.MYSQL 指定数据库类型；如果你的数据库是 PostgreSQL 或 SQL Server，类型要对应修改，否则分页语句会生成错误。联调时，如果发现分页结果异常，第一步不要去看前端，直接打开 SQL 日志，看控制台输出的 SQL 是否带了 LIMIT。这样最快定位是后端插件没生效还是前端参数传错。

5.5 联调和最终演示时的远程调试经验

毕设交付时，常遇到“代码在我电脑上能跑，到对方电脑上就报错”的情况。这时候远程调试是救命的，但要注意，远程调试不是“远程桌面连上去操作”，而是通过 IDEA 的 Remote JVM Debug 功能，连接运行在另一台机器上、已开启调试端口的 Java 进程，然后像本地调试一样打断点、查变量。

开启方式有两种情况：

如果你的 Spring Boot 应用运行在远程机器的命令行里，启动命令改成：

bash复制java -jar express-system-0.0.1-SNAPSHOT.jar \
    -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005

这样应用会在 5005 端口等待 IDE 调试器接入。参数说明：transport=dt_socket 表示基于 Socket 协议通信，server=y 表示作为调试服务端，suspend=n 表示启动时不暂停等待调试器（如果是 suspend=y，没有调试器连接时程序会一直阻塞）。

然后在 IDEA 中点击 Run -> Edit Configurations -> 左上角加号 -> Remote JVM Debug，填远程主机 IP 和端口 5005。运行当前项目时选中这个配置即可。连上后，你在本地代码行左侧打上断点，只要远程应用走到那一行，调试器就会停住，可以查变量。

这里一个常见的坑是：服务器防火墙没放行 5005 端口，或者云服务器安全组规则没加，导致本地 IDE 一直连不上。调试前先用 telnet 测试端口通不通：

bash复制telnet 192.168.x.x 5005

如果通不了，先检查防火墙再检查代码，比对着代码猜半天要高效得多。另外，调试用端口不要用 8080——8080 是应用服务端口，杀进程和调试器接入是两码事。最好是编译时用 dev 环境、机器上没其他 Java 进程占用 5005，减少干扰。

注意远程调试只建议在开发联调阶段开启，正式交演示环境或者部署上线时不要把这个参数放进启动脚本，以免带来额外安全风险。实际操作中如果在一台机器上同一时间只跑一个演示，开着调试问题不大，但演示前几天我一般会把远程调试关掉，避免对方运行时误连调试端口把自己卡住。

6. 功能演示前的“数据造假”策略：让演示效果好一倍的准备

这个部分看的人少，但对答辩很关键。

很多人代码写完了，演示时随便点几页空表格，老师看完觉得系统很简陋。这不是代码不行，而是没有准备演示数据。我在项目里专门写了一个 DataInitializer 初始化类（只在开发环境启用），启动时自动生成测试数据，包含：

• 2 个快递网点，每个网点下挂 3-5 个快递员
• 10 个以上注册用户
• 每个用户名下 3-8 个订单
• 订单分布在“待取件/运输中/派送中/已签收”各个状态
• 每条订单关联 3-6 条物流轨迹，时间按顺序递增

这样打开系统时，首页统计图和列表都是有数据的。老师问“数据哪来的”，可以说“开发环境通过初始化组件自动生成的模拟数据，用于功能演示和接口测试；正式环境接入真实业务数据”。这种回答既诚实，又能体现你对环境区分的理解。

演示时还有一个技巧：准备一条“刚刚创建、处于待取件状态”的订单。当场演示“用户下单 -> 快递员查看大厅 -> 领取任务 -> 更新为揽收 -> 添加运输轨迹”的完整链路，整个过程是实时的，比任何静态截图都更有说服力。

7. 答辩高频问题与回答思路参考

这一节我从几次模拟答辩和现场经验里整理了最常见的几类提问。记住，不是让你背答案，而是给一个回答方向。

问题一：你为什么选择 Spring Boot，而不是 SSM 或者 Servlet？

回答思路：从开发效率角度说，Spring Boot 的自动配置和 starter 机制大幅减少了 XML 配置代码；从生态角度说，Spring Boot 已成为 Java 后端和微服务的事实基础，很多企业和开源框架都围绕它构建；从项目本身角度说，快递管理系统的核心需求是快速开发、稳定运行，Spring Boot 非常适合这种中后台管理类应用。这时候最好能提一嘴“比如我在迁移数据源、配置拦截器时，通过 application.yml 和少量配置类完成，开发效率比传统 SSM 明显高”。

问题二：快递单状态是怎么管理的？如果并发下单会怎样？

回答思路：先讲状态机（哪些状态可以流转到哪些状态），再讲数据库表里的状态字段，再讲代码里每次更新都会校验当前状态。并发下单这块，可以提 MySQL 事务、行级锁和唯一索引兜底。快递员并发抢占任务时，我用条件更新 SQL 来保证只有一个成功，这个点上面已经讲过，能答出来很加分。

问题三：你这系统有什么安全性设计？

这是老师们很喜欢问的一个点，因为几乎每个管理后台都有登录功能。我当时回答分三层：

1. 密码不存明文，用 BCrypt 哈希存储。
2. 登录后发放 JWT Token，前端请求携带 Token，后端用拦截器校验，校验不通过返回 401。
3. 接口按角色鉴权，管理员接口只有管理员 Token 能访问。

实现代码不复杂，Spring Security 如果不想引入太重的东西，也可以用拦截器加上自己写的注解来做。但要注意，答辩时如果你说自己用了 Spring Security，老师可能会往深里问。如果你对 Spring Security 源码不太熟，更稳妥的说法是“项目中采用 JWT + 拦截器实现身份认证与接口访问控制”，把项目做扎实比硬贴框架重要。

问题四：如果用的人多了，你的系统怎么优化？

可以回答从三层考虑：前端静态资源放 CDN，后端 Controller 层接口做缓存（查询多、变更少的如网点列表），数据库对订单表和轨迹表按时间分表。这些优化点到为止即可。关键是你自己说得出来为什么这么做，比如物流轨迹表是增长最快的表，长期运营后按 express_order_id 做分表或索引优化更合理。千万不要说“我用了 Redis 分布式缓存集群”这类你根本实现不了的东西，答辩老师追问两句就会露馅。

8. 写在后面：如果你也是参考别人的源码做二次开发

市面上很多标题带着“源码+文档+远程调试”的项目交易，看起来解决了所有问题，实际上拿到手之后，最容易踩的坑不是代码本身，而是三件事：

第一，项目能不能在你的电脑上直接跑起来。数据库脚本是否齐全、MySQL 版本是否一致、JDK 是否匹配，这些决定了你拿到代码的第一晚是睡好觉还是通宵排错。我的建议是先创建数据库并执行 SQL 脚本，再改 application.yml 中的数据库连接，最后 npm install、npm run serve（如果前端依赖较多的话）这三步走，保证环境出来再谈改代码。

第二，你有多了解这份代码。如果你打算直接拿现成源码去答辩，老师抽一个问题就能看出来你不熟悉系统内部逻辑。我在远程调试帮别人排查问题时见过太多“代码能跑但完全讲不清楚”的案例。建议你拿到源码之后做三件事：看核心表的创建语句，理解表关系；看 Controller 层的接口列表，对比前端页面功能；看订单状态变更的那几个 Service 方法，把状态机画出来。这三件事做完，你对代码的熟悉程度足以应对大部分提问。

第三，远程调试的目标不是帮你解决所有问题。正确用法是代码在本地无法复现、必须在对方环境观察时，通过断点定位问题位置，然后回到自己熟悉的代码上下文中修复。不要指望它帮你自动改 bug，它只是个观察工具。