企业官网建设流程全解析

每年毕业季，后台私信最多的就是“毕设到底做什么”。我的建议一直很明确：能选管理系统就不选别的。尤其是基于Spring Boot的物流中心信息化管理系统，业务链条长、模块多、技术点全覆盖，做完之后既能在简历上写东西，答辩时也扛得住老师追问。这套系统覆盖了客户管理、运单管理、仓储管理、车辆管理、权限管理，用的是最主流的前后端分离方案，适合计算机专业毕业生、准备走Java后端方向的初级开发者，以及想快速搭建一套可演示项目的人。下面我就把整个设计和实现过程完整拆开来说。

项目最初的定位很简单：物流中心内部需要一个平台，把下单、入库、调度、派车、签收这一串动作串起来。以前很多小物流中心靠Excel和电话沟通，运单号靠手记，库存靠脑子估，车辆调度全凭经验。这套系统要解决的就是信息同步和流程留痕的问题。技术上选了Spring Boot 2.7 + MyBatis Plus + MySQL，前端用Vue2 + Element UI，整个项目从零开始搭，前后端加起来大概是30张表、40多个接口的规模。

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

1.1 做物流管理系统，先别急着写代码

很多同学拿到题目第一件事就是新建Spring Boot项目，这是最典型的错误。做系统前最重要的事情是画业务流程图。物流中心本质上就三块业务：订单进来、货进仓库、车拉出去。客户下单之后，仓管员根据订单备货出库，调度员安排车辆和司机，司机运输到目的地后确认签收，最后财务或管理员核对数据收尾。整个闭环缺一环，系统就会变成一张“死表”。

我在需求分析阶段会先用白纸把角色和动作画出来，再翻译成功能模块。实际项目里我拆成了系统管理、基础资料、运单管理、库存管理、车辆管理和统计报表。系统管理负责用户、角色、菜单和登录日志；基础资料维护客户、货物、仓库、司机、车辆这些主数据；运单管理是核心，从下单到签收全流程都由它驱动；库存管理处理出入库和库存查询；车辆管理记录车辆信息和调度记录；统计报表给管理员看每个月的运单量和收入趋势。模块之间不是孤立的，运单出库要调库存接口，调度车辆要读车辆状态，数据流是串起来的。

为什么这么拆？核心思路是“主数据 + 业务单据 + 系统支撑”。客户、司机、车辆、货物是主数据，它们是系统运行的基础；运单、出入库单是业务单据，承载状态流转；用户和权限是系统支撑，保证不同角色各看各的。这个粒度对毕业设计来说刚刚好，不会大到失控，又能体现完整的业务设计能力。

1.2 技术选型：Spring Boot版本别贪新，JDK8够用了

技术栈最终定的是Spring Boot 2.7.18 + MyBatis Plus 3.5.x + MySQL 8.0 + Redis 2.x + Vue2 + Element UI。这里每个选择都有原因，尤其是Spring Boot版本这个坑必须单独讲。

现在不少教程上来就是Spring Boot 3.x，但毕业设计真的不建议用太新的版本。Spring Boot 3要求JDK17起步，很多依赖包里的javax也换成了jakarta，如果答辩环境或者老师那边的机器还是JDK8，项目根本跑不起来。Spring Boot 2.7是2.x时代最后一个大版本，官方维护期足够长，支持JDK8，网上资料最多，遇到问题很容易搜到答案。选它不代表技术旧，而是追求稳定交付，把风险降到最低。

配套选型也有讲究。MyBatis Plus主要省去手写CRUD，自带分页插件，对后端开发效率提升明显；Redis用来存登录token和验证码，不用每天重启服务就掉登录状态；前端没选Vue3和TypeScript，因为Vue2 + Element UI的中后台组件最成熟，两三天就能把页面框架搭完，对毕设来说性价比最高。当然如果你时间充裕，前端换成Vue3也可以，不影响后端设计。

1.3 模块划分与权限设计

系统角色我定了三种：管理员、仓管员、司机。管理员拥有全部权限，可以维护用户和基础资料；仓管员负责库存和出入库操作；司机端只显示我的任务列表和签收入口。不同角色看到的菜单不同，实际操作的数据范围也不同。

权限模型用的是经典RBAC，用户关联角色，角色关联菜单，菜单表里存路由地址和权限标识。登录成功后，后端根据角色返回菜单列表，前端动态渲染左侧导航。这样管理员登录看到系统管理、运单管理、库存管理，司机登录只看到“我的运单”和“签收记录”，用户体验是分开的。

这里要提醒一个很多毕设都会犯的错：只做了前端菜单隐藏，后端接口不做权限控制。直接调用接口照样能拿到数据，答辩时被老师发现就是重大bug。所以在后端也要做一层拦截校验，比如库存接口必须有warehouse:inbound权限标识才允许访问。这个放在后面拦截器部分详细说。

2. 数据库设计与核心表结构

2.1 用户权限三张核心表，字段设计一次到位

RBAC模型的表结构很固定，但字段设计需要细心。sys_user用户表的核心字段：id、username、password、real_name、phone、status、create_time。password字段长度一定要给60，因为BCrypt加密后的字符串长度就是60，有些人建表给32位，一加密就报错。sys_role角色表：id、role_code、role_name、remark，role_code要唯一，比如ADMIN、KEEPER、DRIVER。sys_menu菜单表：id、parent_id、menu_name、path、permission、sort_order。permission字段很关键，比如warehouse:inbound对应库存入库权限，后端权限校验直接比对字符串。

关联表用sys_user_role和sys_role_menu，每张表只需要id、user_id/role_id、role_id/menu_id，再加主键。为什么非要多两张关联表？因为用户和菜单之间是多对多关系，用户可以有多个角色，角色又能挂多个菜单，如果不拆表，后面加一个用户就要复制一堆菜单数据，维护成本极高。

建表SQL可以这样写，简化掉索引部分：

CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, real_name VARCHAR(50), phone VARCHAR(20), status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE sys_role ( id BIGINT PRIMARY KEY AUTO_INCREMENT, role_code VARCHAR(50) NOT NULL UNIQUE, role_name VARCHAR(50) NOT NULL ); CREATE TABLE sys_menu ( id BIGINT PRIMARY KEY AUTO_INCREMENT, parent_id BIGINT DEFAULT 0, menu_name VARCHAR(50) NOT NULL, path VARCHAR(100), permission VARCHAR(100), sort_order INT DEFAULT 0 );

2.2 运单、客户、车辆与司机表，业务字段这样定

运单表是整个系统的核心，字段设计要兼顾业务流程和查询效率。主表是waybill，核心字段如下：

• order_no：运单号，唯一索引，建议用日期+随机数生成，例如202505131030001。
• customer_id：关联客户表。
• goods_name、goods_weight、goods_volume：货物名称、重量、体积，车辆配载时要用。
• start_address、end_address：起点和终点地址。
• status：运单状态，0待揽收、1运输中、2已签收、3异常。
• driver_id、vehicle_id：关联司机和车辆。
• create_by、create_time、update_time：审计字段。

客户表字段比较简单：id、customer_name、contact_name、contact_phone、address、remark。车辆表需要车牌号、车辆类型、载重、体积、状态；司机表需要姓名、手机号、驾驶证号、状态。司机和车辆独立管理，运单通过外键关联，这样统计每一辆车的运单量、每个司机的签收率都很方便。

有一个设计经验需要说明：省市区地址不建议拆成三个字段。毕业设计场景下，物流地址往往是一整串描述，拆字段会增加前端页面的复杂度，导出Excel时还得拼回去。直接一个start_address字符串存储，展示、搜索、打印都很方便。如果以后要做路线规划，再单独拆标准化字段也不迟。

2.3 库存表与出入库状态流转，可用还得防超卖

库存表inventory字段：id、product_id、warehouse_id、quantity、locked_quantity、version。quantity是可用库存，locked_quantity是锁定库存。为什么要有锁定库存？因为在出库流程中，先创建出库单锁定库存，管理员确认出库后再真正扣减，这个过程可能持续几分钟。如果不锁定，另一个用户看到库存还在，可能又把同一批货发给别人。

每次库存变动都要写一条流水，表是inventory_log：id、product_id、warehouse_id、type（1入库、2出库）、quantity、related_order_no、create_by、create_time。库存表记录的是“当前结果”，流水表记录的是“变化过程”，两者配合才能回答“这批货去了哪里”。这也是答辩时一个很好的亮点：你不仅会查总数，还能追溯历史。

version字段是为乐观锁准备的，后面讲并发处理时再细说。简单理解就是每次修改库存时比对版本号，版本号变了就说明有人动过数据，需要重新处理。

3. 后端核心功能实现

3.1 工程目录结构，分清楚每一层的职责

Spring Boot项目我习惯按照功能分包，而不是按技术类型堆在一起。基础结构是：

com.example.logistics ├── config // 配置类：跨域、拦截器、MyBatis Plus分页 ├── common // 统一返回体Result、异常处理 ├── entity // 数据库实体 ├── mapper // MyBatis Plus Mapper接口 ├── service // 业务接口 │ └── impl // 业务实现类 ├── controller // 接口层 ├── dto // 入参对象 ├── vo // 返回视图对象 └── utils // JWT工具、日期工具

这套分层的核心原则是：controller只做参数接收和返回，不写业务逻辑；service里放业务规则；mapper只做数据库操作。很多同学会把查询条件拼在controller里，然后把结果直接返回，导致controller几百行，service空荡荡，答辩时老师一问业务逻辑在哪就答不上来。

实体类用@TableName和@TableId注解对应表。如果需要做一些聚合查询，比如统计每个月的运单量，不要偷懒用实体类接收，直接定义一个VO类，字段按查询结果设计。MyBatis Plus的selectMaps能返回Map，类型不安全，后来我都改成了VO接收。

3.2 JWT登录鉴权与拦截器，别让用户绕过去

登录用的是JWT，不是Session。前后端分离的项目里，Session要处理跨域Cookie、CSRF等问题，很麻烦。JWT把用户信息封装到token里，前端存在localStorage，请求头带Authorization字段，后端无状态解析，部署也方便。

依赖用jjwt，核心流程三步：

1. 用户提交用户名密码，后端查库，BCrypt匹配密码。
2. 匹配成功后生成token，负载里放userId和role，设置过期时间24小时。
3. 前端保存token，请求时放在Header中。

后端写一个LoginInterceptor拦截器，实现HandlerInterceptor接口，在preHandle方法里取token，解析成功就放行，解析失败返回401。解析出的用户信息放到ThreadLocal里，后面业务代码里直接获取当前登录人。

注册拦截器时注意两个细节：登录接口要放行，否则没登录就永远无法登录；静态资源和前端页面如果做了本地访问也要放行。很多人WebMvcConfig里把拦截路径写成了/**，结果登录接口也被拦了，排查半天才找到原因。

核心代码如下：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || !JwtUtil.verify(token)) { response.setStatus(401); return false; } String userId = JwtUtil.getUserId(token); UserContext.setUserId(Long.valueOf(userId)); return true; } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }

3.3 运单状态机，谁允许从“运输中”变成“已签收”

运单状态是业务规则的核心。我只维护四个状态：0待揽收、1运输中、2已签收、3异常。状态不能随意跳转，必须按照规则来：

• 待揽收可以变成运输中，也可以变成已取消。
• 运输中只能变成已签收或异常。
• 已签收和异常是终态，不能回退。

在service里写状态变更方法，比如签收接口：

@Transactional(rollbackFor = Exception.class) public void sign(Long waybillId, Long operatorId) { Waybill waybill = waybillMapper.selectById(waybillId); if (waybill == null || waybill.getStatus() != 1) { throw new BusinessException("当前运单不存在或状态不允许签收"); } waybill.setStatus(2); waybill.setSignTime(LocalDateTime.now()); waybillMapper.updateById(waybill); waybillLogService.addLog(waybillId, "司机确认签收", operatorId); }

签收操作必须加@Transactional。因为更新状态和写日志两个操作必须同时成功，否则状态变了但日志丢了，后面出现纠纷根本没法查。这种设计虽然简单，但能体现你对数据一致性的理解。

每次状态变更还要记录操作日志，表waybill_log可以存waybill_id、action、operator_id、remark、create_time。这样老师看到运单状态变化时，你能清楚说出每一步是什么时候、谁操作的，答辩时很加分。

3.4 库存出入库与并发扣减，用乐观锁防止超卖

库存问题的核心是并发。后台管理系统一般并发量不高，不需要引入分布式锁，用数据库自身的能力就能解决。我在库存表里加了version字段做乐观锁，扣减库存的SQL是关键：

UPDATE inventory SET quantity = quantity - #{quantity}, version = version + 1 WHERE product_id = #{productId} AND warehouse_id = #{warehouseId} AND quantity >= #{quantity} AND version = #{version}

这条SQL做了两件事：一是用quantity >= #{quantity}条件保证库存不会扣成负数；二是用version条件保证数据版本一致。如果更新行数为0，说明要么库存不足，要么版本冲突，业务代码重新查询库存后再提示用户。这个方法比先select再update更安全，因为把判断和更新放在了一条SQL里，数据库层面不会出现并发覆盖。

出库流程完整实现是：创建出库单（状态为待确认），同时锁定库存，调用扣减SQL；管理员确认出库后，把出库单状态改成已完成，写一条库存流水。如果管理员取消出库，锁定库存要释放回来，quantity加回去。

这里的细节是：锁库存和扣库存要用同一个事务，不能分两个方法执行，否则中途异常会导致库存不一致。我把整个出库确认逻辑放在一个service方法里，内部去调mapper，事务的传播行为默认REQUIRED，自然就能覆盖到所有数据库操作。

4. 前端页面与接口联调

4.1 Vue + Element UI的页面骨架，动态路由怎么配

前端不是系统核心，但页面做得好，答辩印象分会高不少。我用的是Vue2 + Vue Router + Vuex + Element UI，典型的后台管理页面骨架：左侧菜单、顶部导航、中间内容区。

登录成功后，前端拿到当前用户菜单列表，用router.addRoutes动态注册路由。这个方案比把所有路由写死在前端更合理，因为不同角色只能看到自己有权限的页面，菜单数据结构由后端返回，前端只做渲染。菜单表里的path字段就是前端路由的路径，permission字段就是按钮级别权限标识。

动态路由最典型的坑是刷新后路由丢失。Vuex是内存状态，刷新就没了，但用户信息存在localStorage里并不会丢。解决方案是在路由守卫里判断Vuex中是否有用户信息，没有就从localStorage恢复，再重新拉取菜单并注册路由。不处理这个问题，页面一刷新就变成空白。

前端接口请求统一用axios封装，加请求拦截器和响应拦截器。请求拦截器把token从localStorage取出来塞到Header里，响应拦截器统一处理后端返回的code。如果code是401，清空登录信息并跳转登录页；如果业务错误，直接提示后端返回的msg。

4.2 统一返回体，前后端少扯皮

前后端接口必须统一返回格式，否则联调时天天吵架。我的Result类很简单：

public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMsg("success"); result.setData(data); return result; } public static <T> Result<T> error(Integer code, String msg) { Result<T> result = new Result<>(); result.setCode(code); result.setMsg(msg); return result; } }

所有controller的返回值都统一用Result包装。分页接口的数据结构也定好，data里包含list和total两个字段，前端分页组件直接绑定。

全局异常处理也要配合。我用@RestControllerAdvice注解写了一个GlobalExceptionHandler，捕获业务异常BusinessException直接返回error，捕获未知异常返回“系统繁忙，请稍后重试”，避免把数据库的SQL异常直接暴露给前端。不然老师随便输入一个非法id，页面上蹦出一串英文错误信息，印象分会很糟糕。

4.3 Excel导入导出和运单面单，加分项别忽略

毕业设计里Excel导入导出是很大的加分项。网上整机项目一般不会单独提这个功能，但实际工作中几乎天天用。我用EasyExcel导出运单列表，后端controller加一个下载接口，把查询结果写入Excel响应流返回给前端。导入客户数据的流程是：前端上传Excel，后端读取后逐条校验，如果某一行数据格式有问题，把错误原因汇总返回给前端，前端在表格里标红。这个流程看起来简单，但能体现“考虑过真实场景”。

运单面单打印直接用浏览器打印。前端把需要打印的运单数据填充到隐藏的打印区域，然后调window.print()，打印样式用@media print隐藏菜单和按钮。为什么不用后端生成PDF？因为要引入额外框架，调试成本高，答辩现场一旦字体异常或者中文乱码，很难快速修复。浏览器打印虽然简单，但效果足够正式。

5. 毕业设计避坑指南：版本、事务与部署

5.1 Spring Boot版本和依赖冲突，最容易栽的坑

版本问题写在最前面，因为十个项目里至少有三个死在这里。创建项目时Spring Initializr默认可能生成最新版本，如果你本地是JDK8，直接跑不起来。解决方法是手动改成2.7.18，新开项目时也可以在start.spring.io里把Spring Boot版本切到2.7.18。

依赖冲突主要集中在Lombok和MyBatis Plus。Lombok在新版本要求JDK17以上，所以JDK8环境下用1.18.30附近的版本比较稳。MyBatis Plus 3.5.x和Spring Boot 2.7兼容没问题，但分页插件要显式配置，代码长这样：

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

没有这个配置，selectPage的结果里total一直是0，很多人排查半天也不知道是分页插件没生效。

5.2 @Transactional失效的几个经典场景

事务失效是面试和答辩高频问题，排查顺序一定要记牢。

• 方法必须是public，否则Spring的AOP代理不生效。
• 同一个类里内部调用不走代理，比如一个方法里调另一个加了@Transactional的方法，事务不生效。解决办法是把两个方法拆到不同类，或者自己注入代理对象。
• 异常被catch住了，事务感知不到，不会回滚。
• 默认只有RuntimeException才能触发回滚，受检异常不行。如果方法里可能抛出受检异常，要在@Transactional注解里指定rollbackFor = Exception.class。
• MySQL要用InnoDB引擎，MyISAM不支持事务，spring.jpa.properties里也要确认方言设置正确。

我习惯在所有写操作的方法上都加@Transactional(rollbackFor = Exception.class)，即使这个异常看起来不会发生，也属于防御性编程。答辩时老师问“如果签收失败，状态会回滚吗”，你能直接答“会，因为方法上有事务注解”，这就是加分点。

5.3 部署上线：Docker Compose一键启动

毕设交付不能只给源码，必须能跑起来。我推荐用Docker Compose把MySQL和应用一起编排，做到一条命令启动项目。

先给Spring Boot应用写Dockerfile：

FROM eclipse-temurin:8-jdk WORKDIR /app COPY target/logistics-system.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

然后docker-compose.yml里定义两个服务：

version: "3" services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: logistics ports: - "3306:3306" volumes: - ./sql:/docker-entrypoint-initdb.d app: build: . ports: - "8080:8080" depends_on: - mysql environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/logistics

注意容器里的数据库地址写成mysql，不是localhost，因为localhost指向的是应用容器自己。很多同学部署时忽略这一点，应用容器和数据库容器之间连不上，卡了一晚上。

5.4 答辩演示时的常见问题与准备

答辩演示比写代码更重要。我这里列几个高频问题，提前准备：

• 为什么用Spring Boot？回答：简化配置、内嵌Tomcat、自动装配原理、生态成熟。
• 密码为什么要加密？回答：BCrypt加盐哈希，防止数据库泄露后密码明文暴露。
• 库存并发怎么处理？回答：乐观锁 + 数据库条件更新，避免超卖。
• 运单状态为什么不能随意修改？回答：状态机校验，非法状态转移直接抛业务异常。
• 前后端如何联调？回答：统一返回体 + axios拦截器，开发时用代理解决跨域。

演示前一定准备一套完整的测试数据，预置几个不同状态的运单、库存数据、司机账号。千万不要现场从零录入，录入过程浪费时间，还容易暴露输入校验的bug。预置数据本身就是你之前做过系统验证的证据，比临时演示有说服力得多。

这套系统我在带毕设学生时反复调整过很多次，最大的体会是：毕业设计并不是技术越难越好，而是要把每个模块闭环打通。宁可少做两个页面，也要保证录单、出库、运输、签收这条主线完整可用。如果你时间紧张，优先实现运单全流程和库存联动，这两个模块是系统亮点，也是答辩时最能讲的点。后面如果要继续扩展，可以加物流轨迹地图、费用结算、数据大屏，这些都能让项目再上一个台阶，但先把基础做扎实最重要。