SpringBoot+Vue物流信息管理系统实战：前后端分离与部署避坑指南

1. 项目整体设计与技术选型

每年毕设季，我都能在技术社区看到大量关于物流信息管理系统的求助帖，内容高度相似：管理员要管订单、管车辆、管司机，用户要能下单、能查物流，最好还能有图表统计。这类项目之所以被反复选中，是因为物流业务天然覆盖了增删改查、状态流转、角色权限、数据可视化这些Java Web课程的必修知识点，但又不像电商系统那样复杂到劝退新手。

我在实际帮人review过几十套毕设代码后发现，很多物流管理系统的核心问题不是功能做不出来，而是架构选型太随意：有人用JSP+Servlet硬扛，前端页面写成一锅粥；有人把Vue全家桶塞进去，但根本没理解前后端分离的边界在哪里。这套“SpringBoot+Vue物流信息管理系统平台”之所以值得拆解，正是因为它走了一条标准化的技术路线，所有环节都指向同一个目标：让你在答辩时能讲清楚每一个技术决策背后的理由。

先看技术选型的底层逻辑。SpringBoot负责后端接口，Vue负责前端交互，MySQL存业务数据，这种组合今天已经算Java Web项目的事实标准。SpringBoot 2.x版本内置了Tomcat容器，省去了传统SSM项目配置各种XML的繁琐步骤，一个注解就能启动Web服务。Vue则把页面渲染从服务端剥离出来，前端只通过HTTP请求和JSON数据打交道，前后端可以并行开发，这也是企业实际项目的主流协作模式。

从毕业设计的角度看，这套组合还藏着一个很实在的优势：答辩老师大概率认识这套技术栈。他们不需要你发明新框架，而是要看到你能把主流的、生产环境正在用的技术熟练组装起来。换句话说，选型本身就在传递一个信号——你的项目不是玩具，而是遵循行业惯例的产品。

1.1 系统角色与核心功能模块拆分

物流信息管理系统说复杂可以很复杂，TMS运输管理系统那套东西做深了能写几百张表。但作为毕设，关键在于业务闭环要完整，角色划分要清晰。我见过最典型的反例是：学生把管理员和普通用户的权限写死在前端按钮上，后端每个接口谁都能调，答辩老师随便一测就露馅了。

这套系统的角色设计应该收敛到三种：系统管理员、物流管理人员（可以理解为内部员工或司机角色）、普通客户。管理员负责基础数据维护，比如用户管理、车辆信息、路线配置；物流人员处理运单流转，从接单、派车、在途更新到签收确认；客户则能在线创建物流订单、支付费用、追踪订单状态。三个角色对应三类接口权限，后端通过拦截器统一校验身份，前端通过路由守卫控制页面入口。

功能模块的划分可以按照业务链路来拆。基础数据模块管用户、车辆、仓库；订单模块管客户下单、订单审核、运单生成；运输管理模块管派车、在途状态更新、签收；统计报表模块管订单量、收入、运输完成率这些核心指标。每个模块其实都是教学里的经典场景：订单状态机、角色权限控制、一对多和多对多关联查询，所有知识点都在业务里落地了。

1.2 为什么前后端分离是这道题的“标准解”

很多人做毕设时会纠结：直接用Thymeleaf把前端页面嵌在SpringBoot里不是更简单吗？确实，单从开发工作量看，传统模板渲染能少写不少代码。但你要明白答辩逻辑——毕设评分看的是完整度和先进性，而前后端分离恰好能同时体现这两点。

前后端分离最大的价值在于职责边界清晰。后端只输出JSON数据，不关心数据长什么样、展示在哪；前端只处理页面交互，不关心数据从哪来、怎么算。这种边界一旦建立，接口文档就变成了联调的契约，你甚至可以先把接口文档定义好，让前端项目和后端项目并行开发互不阻塞。在实际操作中，这意味着你可以在一个周末把后端的增删改查全部写完，然后专心啃前端的交互细节，不需要两头来回折腾。

还有一个容易被忽视的点：前后端分离让部署演示变得更灵活。本地开发时前端用Node服务跑在8080，后端跑在8081，跨域通过代理转发解决；打包部署时前端产物被SpringBoot打成静态资源放进classpath，对外只暴露一个端口，拷贝给老师演示的时候零配置启动。这种部署方式在企业里叫“前后端一体化打包”，答题时顺手讲出来，老师会觉得你懂行。

2. 数据库设计与SQL脚本落地

物流管理系统的数据库设计是整个项目的基石，这块要是糊了，后面写十层缓存也救不回来。给毕设项目做表设计，我总结了一个实用原则：单体项目不要过度设计，但要保证第三范式下的合理冗余和可追溯性。

2.1 核心数据表结构与业务关系梳理

一个功能完整的物流信息管理系统，通常需要8到10张核心表。用户表（sys_user）存登录账号、密码、真实姓名、角色类型和联系方式，这里要注意密码绝不能明文存储，至少要用MD5加盐或者BCrypt加密，答辩时这是个加分点。角色和权限可以合并成一张表里的字段，就没必要为了所谓的规范性去拆出五张权限表，那徒增复杂度而不增加价值。

订单表（logistics_order）是系统的业务核心，字段至少要包含订单编号、客户ID、货物名称、重量、体积、发货地、收货地、运费、状态、创建时间、更新时间。订单状态的流转是这里的灵魂，建议设计为整数枚举：0待审核、1已审核待运输、2运输中、3已签收、4已取消。用int存状态好处是方便比较和流转控制，比字符串更高效，也更容易写状态机的判断逻辑。

车辆表（vehicle_info）关联司机信息，包含车牌号、车型、载重、容积、当前状态（空闲/在途/维修）、司机ID。运单表（transport_order）则把订单和车辆关联起来，包含关联订单编号、车辆ID、司机ID、发车时间、预计到达时间、实际签收时间、在途备注。这里的一对一关系很容易被做砸：有人用外键直接把车和订单硬绑，派车逻辑就全堵死了。正确做法是运单作为中间实体，一个订单可以被指派给不同的车，一个车在生命周期内可以运多张运单，通过时间字段控制并发不冲突即可。基础档案表像仓库表（warehouse_info）、货物类型表可以看时间灵活取舍。

2.2 MySQL执行SQL脚本的正确姿势与常见坑

拿到SQL脚本后，第一步不是急着执行，而是先审视文件结构。规范的脚本文件应该包含建库语句、建表语句、索引创建语句和插入数据语句四段内容。我在帮学生调试时经常遇到“导入一堆红叉”的翻车现场，十有八九是搞错了导入顺序或者字符集不对。

要避免这类问题，记住这个操作顺序：先建库再建表。打开Navicat或者命令行客户端，先执行CREATE DATABASE IF NOT EXISTS logistics DEFAULT CHARACTER SET utf8mb4;，然后切到该库下执行表定义。为什么刻意用utf8mb4而不是utf8？因为utf8在MySQL里连emoji都存不了，虽然业务里不一定用，但统一用utf8mb4是专业习惯。接下来执行索引和基础数据脚本，这一段的顺序也有讲究——先插入角色和用户基础数据，再插入关联业务数据，否则外键校验会让你的导入直接中断。

一个非常隐蔽的坑是SQL脚本中的中文字符乱码。如果脚本文件是UTF-8编码，而你的MySQL客户端默认用的是GBK，导入后你会发现所有中文备注都变成“???”。解决办法是在导入前执行SET NAMES utf8mb4;，或者在Navicat的导入向导里明确选择utf8mb4字符集。另一个高发问题是用source命令导入Windows路径下的脚本时，路径分隔符要写正斜杠/，写成C:\Users\xxx\script.sql会被转义成怪字符，直接写C:/Users/xxx/script.sql才稳。

提示：导入SQL脚本后，第一时间用SHOW TABLES;确认表数量，再用SELECT COUNT(*) FROM sys_user;抽查基础数据行数。很多问题等到启动项目时才发现，排查成本会翻好几倍。

2.3 数据初始化与测试数据设计的门道

测试数据是很多人忽略的细节，但它直接影响演示效果。想想答辩现场的场景：老师随便点了几个菜单，看到表格里空荡荡的连一条数据都没有，第一印象分就垮了。所以SQL脚本里的初始数据要刻意设计得有场景感。管理员账号admin、123456，客户账号user1、user2，密码都用BCrypt加密后的哈希值存在库里。

业务数据方面，准备十个左右订单、五辆车、三个客户、十条在途记录就够用了，关键是状态分布要合理：有待审核的、有运输中的、有已签收的，这样老师点进每个状态标签页都有内容可看。统计报表模块更需要数据支撑，订单创建时间要分布在最近两三个月，最好是近一周有新增，这样图表趋势才好看。我在脚本里习惯把创建时间写成相对时间DATE_SUB(NOW(), INTERVAL n DAY)，这样不管老师是三个月后打开还是半年后打开，图表数据都是“新鲜”的，这个细节很值得抄。

3. SpringBoot后端核心实现拆解

后端项目怎么搭、接口怎么写、权限怎么控，直接决定了这个毕设的含金量。很多人的后端口感不对，把Controller写成只有三行的空壳子，逻辑全堆在Service层，可Service层又只有一行调用Mapper——这就是典型的“伪分层”。好的后端代码应该是：Controller负责参数接收和响应包装，Service负责业务规则，Mapper负责数据访问，每层各司其职。

3.1 SpringBoot项目结构规范与分层职责

一个可以直接参考的标准目录结构是这样的：

src/main/java/com/example/logistics ├── controller // 接收请求、参数校验、返回结果 ├── service // 业务逻辑层，接口+实现分离 ├── mapper // MyBatis数据访问接口 ├── entity // 数据库实体类 ├── dto // 前端交互的数据传输对象 ├── config // 配置类，如跨域、拦截器、Swagger ├── common // 统一返回结果、异常处理、工具类

这里有个重要的设计原则：entity和dto必须分开。有些学生为了少写两个类，直接把数据库实体返回给前端，结果把密码字段也带出去了，这是安全事故级别的低级错误。正确的做法是controller接收时用dto类约束前端传参，返回时也用dto类屏蔽敏感字段。比如保存用户的接口，前端传UserSaveDTO，包含用户名、密码、真实姓名；查询用户列表时返回UserVO，密码字段设置为null或不映射。开工具像BeanUtils.copyProperties或者MapStruct做属性拷贝，一行代码就能完成转换。

Mapper层用的是MyBatis还是MyBatis-Plus？我的建议是直接用MyBatis-Plus。这个选择不是为了偷懒，而是为了降低复杂度——BaseMapper开箱即用地提供了selectById、insert、updateById这些通用方法，分页查询也有内置的Page对象，能让你把精力集中在业务规则而不是重复的CRUD上。当然，复杂的多表关联查询还是要手写SQL。比如统计各状态订单数量，建议直接在Mapper里写一条GROUP BY的SQL，而不是查出全表后在Java里做Stream分组，后者在数据量上来后就是性能灾难。

3.2 统一返回结构与全局异常处理

前后端对接最痛苦的事情就是接口格式不统一。有的接口返回{code:0, data:..., message:"成功"}，有的直接返回一个数组、一个字符串，前端axios拦截器根本没法统一处理。我接手过一套代码，前端每次请求都要写个三元判断，简直是维护噩梦。

标准的做法是定义一个统一的返回结果类Result<T>，包含三个字段：code（200成功、500失败、401未认证）、message、data。controller每个接口都返回这个对象，所有正常流程走Result.success(data)，异常由全局异常处理器统一接管。全局异常处理用注解@RestControllerAdvice实现，里面定义三个核心方法：处理业务异常（自定义BizException）、兜底Exception、处理参数校验异常（MethodArgumentNotValidException）。这样不管哪层抛出错误，前端拿到的永远是结构一致的JSON，前端的全局拦截器只需要判断code就能把提示弹出来。

统一返回结构还会带来一个附加好处：调试接口变成了一件非常舒服的事。不管前端还是后端的同事/队友拿到接口，只要看code和message就能定位问题，不需要对着一堆乱七八糟的响应体猜业务到底有没有跑通。对这个项目来说，你在接口文档里把Result结构定义清楚，后面前端联调能省一半沟通成本。

3.3 登录认证与拦截器权限控制

登录认证是毕设答辩时最高频被提问的模块，问法通常有两种：用户密码怎么存储的、接口怎么保证只有登录用户能访问。先说密码存储，强烈建议使用Spring Security自带的BCryptPasswordEncoder做加密，这个类的hash算法会随机加盐，同一个密码每次加密出来的结果都不一样，安全等级远高于MD5，也省得你自己实现盐值逻辑。在用户表里存的就是BCrypt哈希串，登录时调用encoder.matches(明文密码, 数据库哈希)做比对，这个方法内部会从哈希串里提取盐值再校验，无需你操心细节。

登录成功的凭证建议采用JWT方案。用户验证通过后，后端生成一个token返回给前端，token里可以塞uid、用户名、角色这些关键信息。前端拿到token后存到localStorage里，每次请求在axios请求拦截器中把token放进Authorization头。后端写一个拦截器，继承HandlerInterceptorAdapter或者实现HandlerInterceptor接口，在preHandle方法里校验token的合法性和有效期，校验通过就把token里解析出的用户信息放入ThreadLocal或者request属性，供后续业务取用。

有几个拦截器的坑必须提前说清。第一，放行名单要包含登录接口本身，否则死循环；第二，静态资源要放行，如果你的前端页面是后端打包的，拦截器不能拦/static/**和/favicon.ico；第三，跨域预检请求OPTIONS要直接放行，否则前端浏览器会在预检阶段就被拦下来。在WebMvcConfigurer里注册拦截器时，写清楚excludePathPatterns("/api/auth/login", "/api/auth/register", "/doc.html", "/webjars/**")这些路径，这部分配置经验是踩过无数遍坑才积累下来的。

3.4 接口文档生成与后端测试要点

接了口文档，这个项目的实用性就完整了。手动写Word接口文档费时费力还容易和代码脱节，正确的做法是用Swagger/knife4j自动生成。引入springfox或springdoc依赖后，在启动类加上@EnableSwagger2注解，访问/swagger-ui.html或者knife4j美化后的/doc.html就能看到所有接口的在线调试页面，每个接口的入参、出参、必填项全部清晰展示，前端同学直接在这个页面上测试参数组合，比自己一堆Postman collection高效得多。

但要注意，Swagger不是加上就完事了。接口注释要写到Controller的方法上，配合@ApiOperation("根据ID查询订单详情")、@ApiImplicitParam(name="orderId", value="订单ID", required=true, paramType="path")这些注解，文档的可读性才会好。学生经常犯的错误是给实体类加了@ApiModelProperty但Controller方法什么都没写，生成的文档里全是“查询”“保存”这类没头没尾的描述。

后端接口写完后，测试顺序建议是：先用Swagger页面把所有接口正向调一遍，确认每个接口返回结构符合Result<T>规范；再故意传错参数、传空参数，确认全局异常处理器能兜住错误并返回500或400。最后把token故意改成乱串访问受保护接口，确认拦截器会返回401。这三轮测试跑完，后端接口的健壮性在毕设答辩这个级别上就非常能打了。

4. Vue前端工程化实现要点

前端部分的坑往往比后端还多，不是因为逻辑复杂，而是环境配置的坑防不胜防。SpringBoot项目只要JDK版本对、Maven依赖拉下来，基本跑得起来；Vue项目则要过Node版本、依赖安装、代理配置、构建打包好几道关卡，每一步都可能卡住半小时起跳。

4.1 Vue环境准备与项目初始化实战

这里集中说“vue安装及环境配置”这个高频问题。开发Vue项目需要两个底层设施：Node.js和npm（或者用yarn/pnpm）。Node.js装LTS版本就好，不要追求最新版，很多老项目在Node 18+上跑起来会有OpenSSL兼容性报错，还得加NODE_OPTIONS=--openssl-legacy-provider才能编译，完全没必要自己折腾这个。装完在命令行输入node -v和npm -v验证版本号正常，环境就算搞定。

创建项目我推荐使用Vue CLI。执行npm install -g @vue/cli安装脚手架，然后vue create logistics-web进入交互式配置。组件库建议选Element UI或者Element Plus，图标、表格、表单、分页组件都齐了，专门用来做管理后台这种中后台界面。要不要引入TypeScript？我的建议是毕设项目别上，理由很简单：TypeScript的泛型和类型体操会大幅增加编码时间，而答辩时没人关心你是不是用TS写的，他们关心功能能不能跑起来。

项目初始化完成后，第一步是把目录结构调整好：src下建立api、router、views、components、utils五个目录。api目录按模块拆文件，比如order.js里统一封装订单模块的所有请求；router目录配路由表；views目录放页面组件；components目录放可复用的业务组件；utils目录放axios实例和工具函数。这个结构不一定多高级，但胜在直观清晰，自己维护起来不迷路。

4.2 Axios封装、跨域代理与请求拦截

前端请求后端最大的坑是跨域。假设前端跑在http://localhost:8080，后端跑在http://localhost:8081，浏览器会因为同源策略拒绝前端发出的Ajax请求。解决跨域在开发环境的最佳实践不是在后端加@CrossOrigin注解（虽然那也是一种办法），而是在前端配置代理转发。

在vue.config.js里配置devServer.proxy，把/api前缀的请求转发到http://localhost:8081，表面上浏览器还是请求的同源地址，实际由Vue开发服务器转发到了后端，浏览器感知不到跨域存在。配置代码大致长这样：

module.exports = { devServer: { port: 8080, proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true } } } }

request.js里的axios封装也值得好好写。建议创建一个axios实例，配置baseURL为/api，设置10秒超时时间，然后在请求拦截器中统一从localStorage读token并放进header，在响应拦截器中统一处理code：200时直接返回data给业务层；401时清除本地登录态并跳转登录页；其他错误码用Element的Message组件弹出后端返回的message。这样的封装一劳永逸，业务页面里不需要再做任何重复的错误处理。

4.3 路由配置、状态管理与权限控制的落地写法

Vue Router的配置要点有两个：一是路由懒加载，二是路由守卫。懒加载写法很简单，在路由表里把组件写成() => import('@/views/order/OrderList.vue')的形式即可，这样打包时每个页面单独成一个chunk，首屏加载速度快很多，答辩演示时候页面秒开很加分。

路由守卫是权限控制的第一道防线。在router.beforeEach里读取本地token，如果访问的页面要求登录而token不存在，直接重定向到登录页。再进一步，可以通过登录时拿到的角色字段，动态判断当前用户能否进入某个路由。但这里要注意一个边界：前端路由守卫只能控制页面是否渲染，真正的数据安全靠后端的拦截器保证，前端路由守卫做的是体验层面的控制——避免没有权限的用户看到不该看的菜单和页面。

状态管理方面，Vuex或者Pinia二选一。简单项目其实只用Vuex存两样东西：用户信息和token，根本不需要拆那么多module。如果项目使用了Vue3，直接用Pinia更清爽。很多毕设对状态管理的使用流于形式，在组件里用props层层传递，结果传得头皮发麻。快递状态、当前用户这些需要跨组件共享的数据，全部走状态管理才是正统做法。

4.4 订单列表、表单、物流时间线等核心页面实现思路

订单列表页是整个前端最核心的页面。以订单模块为例，页面结构标配是：顶部搜索栏（订单编号、状态、客户名）、中间操作栏（新建、批量导出）、主体表格（订单信息、状态标签、操作列）、底部分页条。Element的el-table加el-pagination组合把这套东西拉出来很快，分页选择器绑定在data里的pageNum和pageSize上，页码或条数变化时触发查询函数重新拉取数据。

物流轨迹追踪是一个能体现项目用心程度的功能。建议使用el-steps组件或者声网的日历时间线组件来做展示，把运单状态从“待审核”、 “已派车”、“运输中”、“已签收”这几个节点串成走马灯式的步骤条，每一步的时间显示在节点下方。如果不想用组件库的样式，手写div布局加CSS也可以，配上不同状态对应的不同颜色，视觉上比纯粹的表格展示要生动得多，答辩加分明显。

表单页面的实现套路就是el-form加rules校验，重点在于校验规则的编写。订单创建表单至少要校验货物名称非空、收货地址合法、重量必须在0到100吨之间，这些规则用{ required: true, message: '请填写货物名称', trigger: 'blur' }的方式配置，编辑器里会有提示，运行时也会在提交时自动拦截并提示。联动场景也不能忽略：选择车辆时自动带出该车司机信息和载重限制，超出载重就提示“车辆载重不足”。这种细节功能代码量不大，但非常显“系统完整度”。

5. 系统部署、联调与答辩避坑指南

项目写完只是完成了一半，能够顺畅地启动、展示、回答老师的追问才算真正的收尾。这一节我把毕设项目最容易翻车的环节集中盘点一下，全是实战中的高频事故现场。

5.1 版本兼容性排查：SpringBoot版本不能乱选

开篇提过“springboot版本太高”是常见问题。SpringBoot的版本演进非常快，从2.x升级到3.x后，底层发生了破坏性变化：javax.servlet包名变成jakarta.servlet，很多老教程和依赖的写法全部失效。如果你在网上找的参考代码是SpringBoot 2.3的写法，而你在项目里用了SpringBoot 3.2，那大概率一启动就报错，或者一堆依赖拉不下来。

对于这个毕设项目，我的明确建议是选择SpringBoot 2.7.x版本，这是2.x系列的最后稳定版本，兼容性最好，网上的参考资源也最多。配套的依赖版本要一起锁定：MyBatis-Plus使用3.5.x，Swagger使用knife4j的3.0.3版本，JWT使用0.9.1或jjwt 0.11.x。在你搭建项目骨架时，先去Maven仓库确认这些版本的真实存在性，不要凭记忆填版本号，否则本地Maven会疯狂报错“Could not find artifact”，这个问题在毕设季我几乎每周都能遇到。

5.2 前后端联调与部署打包实操流程

本地联调的标准流程是这样的：先启动后端项目，确认端口8081成功监听；再启动前端npm run serve，确认8080端口页面能打开。这时在页面点击登录，如果F12控制台显示请求被代理成功转发到后端且接口返回200，联调就基本通了。如果看到的是404，先排查proxy配置的路径和后端RequestMapping的路径是否一致；如果是500，去后端控制台看异常栈。这是最基础的bug定位流程，但很多人卡住是因为连“前后端日志分开看”的意识都没有。

打包部署阶段，前端在项目根目录执行npm run build，产物会输出到dist目录。后端的部署有两种思路：第一种是强迫症做法，前后端完全分离部署，后端打jar包跑8081，前端dist目录扔给Nginx托管8080端口；第二种是省事做法，把前端dist目录复制到SpringBoot项目的src/main/resources/static目录下，然后重新打成jar包，直接java -jar一键启动，浏览器访问8080端口就能看到完整系统。毕设演示场景强烈推荐第二种，因为Copy给老师时只需要给一个jar文件加一个SQL脚本，打开方式极其简单，老师演示时零基础也能跑起来。

5.3 典型报错排查实录与解决速查表

这里把毕设过程中最高频的报错信息做一个速查表，按问题现象、产生原因、解决办法三列列出。你照着实操能节省大量排查时间。

5.4 答辩必须讲清的三板斧

答辩环节老师通常不会让你从头到尾演示所有功能，时间有限，他们更关注三个核心话题：架构合理性、核心难点、你的工作量真实性。

架构部分，用两分钟讲清前后端分离的结构、数据库的ER关系足矣。指出“订单-运单-车辆”之间的关联是一对多还是多对多，就这一个小点能直接证明你吃透了业务。核心难点部分，把智能派车逻辑或者订单状态机讲清楚：比如当客户下单后系统如何自动或手动选择一辆当前空闲的车辆创建运单，在途状态如何流转。这部分不怕讲得细，越细越能体现真实性。工作量真实性嘛，用代码量说话要讲究策略：不虚报“两万行代码”，但要准确说出每个模块的实现点了哪些技术、写了哪些核心方法、解决了什么问题。

另一个容易被追问的点是“你做了什么优化”。哪怕你只是做了数据库索引、分页查询、懒加载、JWT无状态认证，也要把这些在答辩前准备好一段流利的描述。讲的时候用说人话的表达：“我给运单表的订单编号字段加了联合索引，因为列表页按这个字段查询最多；列表页从一次性把几万条数据全查出来改成了后端分页，前端只拿当前页的十条。”这种接地气的回答远比背概念自然。

6. 项目复盘与扩展建议

写到最后，分享一些个人实际操作中的体会。物流信息管理系统这类Java Web毕设，最大的价值不是把代码堆出来，而是通过一个完整业务需求贯穿了从前端交互、后端接口、数据库设计到部署上线的全套流程。我见过太多学生把重点放在“功能能不能跑”上，却忽略了“每个接口为什么这么设计”“每个表为什么建这些字段”这些设计层面的思考——而这些往往才是区分优秀毕设和普通毕设的分水岭。

实操过程中一个很容易被低估的点是接口文档的维护。很多人写完代码就忘了写注释，结果答辩前两天自己看着几个月前的代码都发懵。从项目一开始就养成分层写注释、在Swagger上补描述的习惯，后面会省下大量痛苦时间。日志也是同样道理，在关键业务节点加上log.info打印，联调时对着日志排查问题比瞎猜快十倍。

这个项目后续还可以这样扩展：加入MySQL的定时备份任务，每天凌晨自动dump数据；接一个高德或百度地图的API实现线路规划和轨迹回放，这是物流系统天然的增强方向；把图表统计从简单柱状图升级为ECharts的趋势图和热力图；甚至可以引入RabbitMQ做订单创建后的异步通知，这些点每个都能变成答辩时的加分亮点。但扩展的前提是基础链路已经跑得非常稳，先确保百分之百可复现的稳定，再去谈花活，这是我对所有做毕设的同学最真诚的建议。