简介这是基于Java开发的货运搬运管理系统源码包面向具有一定Java基础的开发者、物流信息系统初学者及需要完成课程设计或毕业设计的高校学生覆盖货运订单管理、搬运任务调度、用户权限控制等典型业务场景可作为理解物流类Web项目从建表到接口实现全过程的学习样本。资源包共121个文件其中56个Java源文件构成核心业务逻辑23个XML文件承担框架配置与数据映射14个properties和3个yaml文件用于数据库、端口等多环境参数设置17个Markdown文档提供阅读说明整体压缩包仅111KB轻量且便于在常见IDE中打开部署。从内容预览可见源码按traffic-api、entity、interface、commons、resultCode等模块拆分包含用户管理、统一异常处理与返回码封装清晰展示Controller-Service-Entity分层阅读时可借助模块边界快速定位业务代码并参考配置类文件理解多环境切换方式。模块化组织对后期维护与功能扩展都比较友好。已有373人学习这份源码包适合用于理解Spring Boot风格的业务系统开发思路并可在本地启动、改造和扩展是货运搬运场景下值得参考的Java源码练习素材。1. 拿到「Java货运搬运系统源码.zip」先别急着解压导入「Java货运搬运系统源码.zip」这个名字里最值钱的不是那几张业务表而是它展示了一个中等复杂度的 Spring Boot 工程里运单、车辆、装卸、计费这几条业务线是怎么被串起来的。货运搬运系统和普通进销存系统最大的差别在于每张运单都对应真实的物理动作——车要派出去、货要装卸、人要计工钱所以状态流转和任务分派比单纯的数据增删改查难设计得多。这套源码适合两类人一类是需要快速交付货运管理后台的 Java 工程师拿来改改就能用另一类是准备面试、想看懂一个真实业务系统的后端初学者跟着源码走一遍比刷一百道 java 面试题都管用。拿到 zip 之后我建议你先做环境核对再谈导入和改造这一步能帮你避开后面八成的问题。2. 先做这四件事环境核对、建库导数据、改配置、首次启动2.1 核对 JDK 和 Maven 版本别让编译错误浪费第一个小时解压 zip 之后我习惯先扫一遍工程特征而不是直接双击 pom.xml 用 IDE 打开。货运搬运系统这类业务后端十有八九是 Spring Boot MyBatis 的组合JDK 版本直接影响能不能编过。Spring Boot 2.x 时代JDK 8 是最稳的如果工程的 pom.xml 里出现了spring-boot-starter-parent版本是 2.3.x 或 2.4.xJDK 8 和 JDK 11 都能跑但 JDK 17 会把很多旧版 Lombok 和 javax 命名空间直接挡在门外。# 1. 确认当前 JDK 版本目标看到 1.8 或 11 java -version # 2. 确认 Maven 可用 mvn -v # 3. 解压后先列目录找 README、SQL 脚本和 pom.xml unzip Java货运搬运系统源码.zip -d freight-src cd freight-src find . -maxdepth 2 -name *.sql -o -name README* -o -name pom.xml第一步的三条命令第一条和第二条是检查本机基础环境第三条是摸清源码包里有什么。很多 zip 包里会同时放db/init.sql、doc/接口说明.md这类文件先看清单能避免你拿着一个只有前端的模块当后端入口或者在无 SQL 脚本的情况下硬猜表结构。这里有个小经验如果压缩包里的src/main/resources下没有application.yml而是在src/main/java里用PropertySource加载 properties 文件说明源码作者习惯用传统方式管理配置你要找的数据源配置位置就不一样别找错方向。2.2 建库导数据先看 SQL 脚本里的建库语句是哪个版本货运搬运系统的数据初始化通常给一份freight.sql或init.sql里面可能带CREATE DATABASE语句也可能只有建表和 INSERT 数据。常见做法是先用 MySQL 客户端建一个独立库再导入脚本。注意字符集统一用utf8mb4否则后面运单里出现收货人姓名带生僻字或表情符号时会直接写入失败或者变成问号。-- 1. 建库库名建议和工程里 application.yml 保持一致 CREATE DATABASE IF NOT EXISTS freight_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 2. 选择库并导入脚本在终端执行不是 SQL 客户端里手动跑 USE freight_db; SOURCE /path/to/sql/freight.sql;导入之后做一次快速校验查一下核心表的数据量是否正常。比如运单表t_waybill如果初始化有几百条模拟数据而导入后只有 0 条基本可以判断脚本执行时发生了静默失败常见原因是建表语句里用了 MySQL 8 的新语法但你的连接账号版本是 5.7。另一个排查点是外键约束如果脚本里建表顺序不合理先建了明细表再建主表导入时会出现Cannot add foreign key constraint解决方法是把脚本里的SET FOREIGN_KEY_CHECKS0;放到文件头部。2.3 配置文件的三个必改点数据源、上传路径、日志级别导入数据之后打开application.yml或application.properties优先改三个位置不要一上来就改业务代码。server: port: 8080 # 如果 8080 被占用改成 8090 spring: datasource: url: jdbc:mysql://localhost:3306/freight_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password # 改成你本机 MySQL 的密码 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 20MB # 运单凭证图片常大于默认 1MB max-request-size: 50MB file: upload-dir: ./upload # 改成你希望存放装卸照片的本地目录 logging: level: com.freight.mapper: debug # 打印 MyBatis SQL排查问题必备这里三个参数值得单独说明。serverTimezoneAsia/Shanghai是 JDBC 连接 MySQL 8 时最容易漏的不配它大概率报The server time zone value错误multipart.max-file-size决定搬运凭证、回单照片能不能上传成功默认 1MB 对于手机拍照的图几乎必炸logging.level里的 MyBatis 日志级别调成 debug 后你能在控制台看到每一条执行的 SQL 语句这是排查业务逻辑问题的第一把钥匙。2.4 首次启动用 Maven 直接跑不依赖 IDE配置改完先不用 IDE 打开工程直接在命令行启动一次。这样能把「编译问题」和「运行时问题」分开不会一上来就被 IDE 的红线干扰判断。# 进到源码根目录执行打包跳过测试能省很多时间 mvn clean package -DskipTests # 如果打包成功用 java -jar 启动 java -jar target/freight-system-1.0.0.jar启动日志里关注两个标志Spring Boot 的Started Application in xx seconds和 Tomcat 的Tomcat started on port(s): 8080。看到这两行说明工程本身没问题。如果启动失败第一优先看错误堆栈的前三行多半是数据源连不上或端口被占用。连不上时回头检查 2.2 和 2.3 的库名、密码、时区端口占用就用netstat -ano | findstr 8080Windows或lsof -i:8080Linux找到占用进程把配置改到 8090 是最省事的做法。首次启动成功后打开浏览器访问http://localhost:8080/能看到登录页或接口文档页就说明这套源码已经活过来了。3. 读懂核心模块运单状态机、车辆调度与装卸任务的数据结构3.1 运单主表与状态流转从提单到结算状态字段怎么设计最实用货运搬运系统的地基是运单表。不管界面做得多花哨后端最终都是围绕运单的status字段做流转判断。源码里常见的状态设计是0 待派车→1 已派车→2 装货中→3 运输中→4 已签收→5 已结算外加一个-1 已取消作为异常分支。用整数而不是字符串存状态是为了在 Mapper XML 里写if teststatus ! null and status 2这类条件时更省事也避免各人写代码时把「运输中」写成「在途」这种不一致的值。-- 运单主表的典型结构从源码里提炼的核心字段 CREATE TABLE t_waybill ( id BIGINT PRIMARY KEY AUTO_INCREMENT, waybill_no VARCHAR(32) NOT NULL COMMENT 运单号业务唯一, customer_id BIGINT NOT NULL COMMENT 客户ID, pickup_address VARCHAR(255) NOT NULL COMMENT 提货地址, deliver_address VARCHAR(255) NOT NULL COMMENT 送货地址, cargo_weight DECIMAL(10,2) DEFAULT 0 COMMENT 货物重量(吨), cargo_volume DECIMAL(10,2) DEFAULT 0 COMMENT 体积(方), freight_amount DECIMAL(10,2) DEFAULT 0 COMMENT 应收运费, driver_id BIGINT COMMENT 当前绑定的司机, vehicle_id BIGINT COMMENT 当前绑定的车辆, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态 0-待派车 1-已派车 2-装货中 3-运输中 4-已签收 5-已结算 -1-已取消, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT运单主表;这张表设计上的关键点是把driver_id和vehicle_id放在运单主表而不是单独一张调度表。对于中小型搬运公司一辆车一次只服务一个运单这种冗余设计反而让查询更简单——你要知道某个司机目前在跑哪个单一条 SQL 就能查出来。如果想支持「一次派车跑多个运单」的拼车场景源码的后续版本一般会拆出t_dispatch表但基础版这么做是够用的。3.2 车辆与司机档案两张基础表的关联查询是怎么做的车辆表和司机表在货运系统里属于基础档案但它们在派车页面上的关联逻辑值得学习。源码里的做法是车辆表和司机表各自独立中间通过运单表的driver_id和vehicle_id产生业务关联而不是在司机表里冗余一个vehicle_id。这样设计的直接效果是一个司机可以换开不同车辆一个车辆也不会被单一司机绑死。!-- Mapper XML 中的派车列表查询关联运单、司机、车辆三张表 -- select idselectDispatchList resultTypecom.freight.vo.DispatchVO SELECT w.id AS waybillId, w.waybill_no AS waybillNo, w.pickup_address AS pickupAddress, w.deliver_address AS deliverAddress, d.driver_name AS driverName, d.driver_phone AS driverPhone, v.plate_no AS plateNo, w.status AS status FROM t_waybill w LEFT JOIN t_driver d ON w.driver_id d.id LEFT JOIN t_vehicle v ON w.vehicle_id v.id WHERE w.status IN (0, 1, 2) ORDER BY w.create_time DESC /select这个查询的要点在于用LEFT JOIN而不是INNER JOIN。在派车完成前运单的driver_id和vehicle_id是空的如果用内连接未派车的运单直接就从列表里消失了这显然不符合业务预期。源码里用外连接配合WHERE status IN (0,1,2)既能显示待派车的单也能显示已派车但还没装货的单是这类管理页面最常见的写法。面试时如果被问到「为什么这里用 LEFT JOIN」答案就在这个场景里。3.3 装卸任务分派一张任务表如何支撑「一次性同时装几车货」搬运和装卸是货运系统区别于普通物流系统的关键模块。源码里通常会有一张t_load_task表记录每个装卸任务的开始时间、结束时间、参与人员、装卸类型装货/卸货以及关联的运单 ID。注意这里没有把装卸人员做成任务表里的一对多子表而是用workers字段以逗号分隔存司机或装卸工 ID这种反范式设计在读取时一次查询就能拿到完整的参与人员列表但代价是无法直接用 SQL 统计某个工人的工作量。源码作者选这个方案大概率是默认中小团队装卸工数量不多统计频率也不高。-- 装卸任务表的核心结构 CREATE TABLE t_load_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, waybill_id BIGINT NOT NULL COMMENT 关联运单, task_type TINYINT NOT NULL COMMENT 1-装货 2-卸货, worker_ids VARCHAR(255) COMMENT 参与人员ID逗号分隔, start_time DATETIME COMMENT 实际开始时间, end_time DATETIME COMMENT 实际结束时间, remark VARCHAR(255) COMMENT 装卸备注, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT装卸任务表;如果你准备在这个源码基础上做二次开发我建议把worker_ids拆成一张t_task_worker关联表。拆分理由很实际当你要做「某装卸工本月参与了多少次装卸」的绩效统计时FIND_IN_SET在这种场景下性能很差而且worker_ids字段的数据完整性没法靠数据库约束保证。这是源码里少数几个你会发现「它为了快速交付做了取舍但你需要为业务发展把它改规范」的地方。3.4 计费模块按趟、按吨、按里程三种计费并存怎么设计货运搬运的计费规则通常不是单一的。搬到一楼的货物按趟算拉到工地的沙子按吨算跑长途的按里程算。源码里的计费设计一般是在运单表里放fee_type字段1-按趟 2-按吨 3-按里程然后配一张t_fee_rule规则表存基础价和单价计算时由后端 Service 层根据fee_type分支处理。这种做法逻辑清晰但扩展性一般——如果以后要按「体积×单价」或者按「重量段递增」计费就得改 Service 代码。// 计费计算的核心逻辑按费用类型分支返回应收金额 public BigDecimal calculateFreight(Waybill waybill, FeeRule rule) { // rule 里有 basePrice 起步价、unitPrice 单价 if (waybill.getFeeType() 1) { // 按趟直接返回起步价 return rule.getBasePrice(); } else if (waybill.getFeeType() 2) { // 按吨重量 * 单价不足一吨按一吨取整 BigDecimal weight waybill.getCargoWeight(); return weight.multiply(rule.getUnitPrice()); } else if (waybill.getFeeType() 3) { // 按里程里程 * 每公里单价 return waybill.getMileage().multiply(rule.getUnitPrice()); } // 默认按 0 处理避免返回 null 导致后续 NPE return BigDecimal.ZERO; }这段逻辑有三个细节值得注意。第一个是BigDecimal.ZERO兜底如果判断条件有遗漏返回值不会让上层代码空指针第二个是计费结果建议保留两位小数setScale(2, RoundingMode.HALF_UP)一般放在返回给前端之前做第三个是运费计算和最终结算要分离——运单创建时算出的金额是「应收预估」签收后根据实际重量或实际里程再算一次这个差异在很多项目里都是对账纠纷的来源。源码里如果只在一个地方调用calculateFreight你就要看看它是在签收动作里调的还是在创建运单时调的这决定了金额会不会在后续修改运单信息时更新。4. 二次开发落地加字段、加接口、对接移动端的三条实践主线4.1 给运单加一个「保价费」字段SQL、实体、Mapper、接口、前端一通改拿到源码后最常见的需求是加字段。比如客户要求运单上多一个「保价费」以便贵重货物单独计费。完整的改动链是先改数据库再改 Java 实体再改 Mapper XML 的 resultMap 和 insert/update 语句最后改前端表单。很多人只改了实体和数据库结果插入时报错「字段列表和值列表不匹配」就是因为漏了 Mapper XML 里写死的列名。-- 第一步数据库加字段带默认值避免存量数据报错 ALTER TABLE t_waybill ADD COLUMN insurance_fee DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 保价费;// 第二步实体类加属性类型和数据库字段对应 private BigDecimal insuranceFee;!-- 第三步Mapper XML 的 insert 语句里加上字段注意所有列名和 #{} 里一一对应 -- insert idinsertWaybill parameterTypecom.freight.entity.Waybill INSERT INTO t_waybill ( waybill_no, customer_id, pickup_address, deliver_address, cargo_weight, cargo_volume, freight_amount, insurance_fee, status, create_time ) VALUES ( #{waybillNo}, #{customerId}, #{pickupAddress}, #{deliverAddress}, #{cargoWeight}, #{cargoVolume}, #{freightAmount}, #{insuranceFee}, #{status}, NOW() ) /insert这段 XML 的逻辑说明就一句话MyBatis 的 insert 语句不会自动同步你实体类新增的属性resultMap里的自动映射只有数据库列名和属性名完全一致时才生效。加字段后最稳的验证方式是在启动项目后调用一次「创建运单」接口看控制台打印出来的 SQL 里是否包含insurance_fee字段。如果插入成功但页面不显示那就是前端表格没加列如果插入直接就报Unknown column insurance_fee in field list说明你只改了实体没改 XML或者数据库脚本没执行成功。4.2 新增一个「车辆利用率统计」接口从需求、SQL 到 Controller 的完整链路加字段是横切改动加接口是纵向打通。常见的运营需求是「统计本月每辆车的出车天数」用来评估车辆是否闲置。这个需求不复杂但很典型因为它涉及分组聚合和日期去重。-- 统计某月每辆车的出车天数以运单表为准按车辆分组统计不重复日期 SELECT v.plate_no AS plateNo, COUNT(DISTINCT DATE(w.create_time)) AS activeDays FROM t_waybill w LEFT JOIN t_vehicle v ON w.vehicle_id v.id WHERE w.status ! -1 AND w.create_time 2025-06-01 AND w.create_time 2025-07-01 GROUP BY w.vehicle_id, v.plate_no ORDER BY activeDays DESC;这条 SQL 的核心是COUNT(DISTINCT DATE(...))。如果同一天同一个车跑了好几单直接用COUNT(*)会把出车天数放大好几倍这是统计报表里最常见的逻辑错误。表关联用LEFT JOIN而不用INNER JOIN是为了把那些有运单但车辆信息被删掉的脏数据也统计出来方便你发现基础档案的问题。把这句 SQL 放到 Mapper XML 里对应一个selectVehicleUtilization方法然后在 Service 层包一层返回列表Controller 加一个/api/report/vehicle-utilization接口前端用 ECharts 画个柱状图这就能完成一个真正能见人的报表功能。4.3 对接移动端扫码和司机打卡不改造源码也能实现的接口方案货运搬运系统常常需要配合移动端使用司机在装货现场扫码确认运单、装卸工到达后打卡签到。如果源码本身没带移动端最常见的做法是给现有后端补两个轻量接口让微信小程序或企业微信应用直接调用。这里的关键是「身份认证」——司机登录不能走后台管理系统的账号体系要单独做一层简单的 token 鉴权。常见做法是让司机用手机号作为用户名默认密码首次登录强制修改登录成功后返回一个 UUID token后续请求头带上Authorization: Bearer token。// 司机扫码确认运单的接口实现要点先验 token再查运单最后改状态 PostMapping(/api/driver/waybill/confirm) public ResultString confirmWaybill(RequestHeader(Authorization) String token, RequestParam String waybillNo) { // 1. token 里解析出司机 ID查不到说明登录过期 Long driverId tokenService.getDriverId(token); if (driverId null) { return Result.error(401, 登录已过期请重新登录); } // 2. 查运单校验司机是否被派到此单 Waybill waybill waybillService.getByNo(waybillNo); if (waybill null || !waybill.getDriverId().equals(driverId)) { return Result.error(400, 运单不存在或未指派给当前司机); } // 3. 只有已派车状态才能确认防止重复操作 if (waybill.getStatus() ! 1) { return Result.error(400, 当前运单状态不允许确认); } // 4. 更新状态为装货中 waybillService.changeStatus(waybill.getId(), 2); return Result.success(确认成功); }这段代码的逻辑说明围绕状态机的规则展开。第 2 步校验「司机是否被派到运单」是业务安全的底线不然任何司机拿一个运单号就能乱改状态第 3 步是状态机的防重校验确保运单只能从「已派车」变成「装货中」不能从「已签收」跳回「装货中」。实际做对接时移动端扫码的二维码内容可以就是运单号或者带一个签名参数防止有人手动输入运单号调接口这些属于安全加固源码交付后建议在正式上线前补上。5. 避坑记录Java 货运搬运系统部署与改造中的 5 个典型问题5.1 现象启动时报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized第一次启动就遇到这个报错人很容易慌因为错误信息里的中文直接乱码了。原因很简单MySQL 8 的 JDBC 驱动要求客户端显式告诉它服务器时区而默认驱动和 MySQL 的时区协商对不上。解决方式是在 JDBC URL 里加上serverTimezoneAsia/Shanghai。jdbc:mysql://localhost:3306/freight_db?serverTimezoneAsia/ShanghaiuseSSLfalsecharacterEncodingutf8这个坑的关键不在加不加参数而在加的位置。它必须放在 URL 的查询参数里不能写在spring.datasource的其他属性上。另外如果你的 MySQL 服务器设置了非标准时区比如CST拉美地区的时区缩写也叫 CST驱动可能还是识别不了这时候直接把 MySQL 的default-time-zone设为08:00最省事。5.2 现象页面和数据库里凡是中文都变成问号中文乱码是 Java Web 项目的经典问题货运搬运系统里出现的位置一般在两个一个是导入 SQL 脚本时建表数据的注释和初始化数据变成问号另一个是页面上新增运单后收货人地址在数据库里变成???。第一个的根源是 SQL 文件本身的编码不是 UTF-8用记事本打开另存为 UTF-8 或者用source命令前先执行set names utf8mb4就能解决。第二个的根源是 JDBC 连接串里虽然写了characterEncodingutf8但 MySQL 表的字符集实际是latin1驱动按 UTF-8 编码写入表按 latin1 解析必然乱套。排查时先执行SHOW CREATE TABLE t_waybill看到DEFAULT CHARSETlatin1就立刻ALTER TABLE改成 utf8mb4不要只改连接串。5.3 现象运单凭证图片传不上去报MaxUploadSizeExceededException装卸现场拍的照随手一拍就是 3MB 到 5MB而 Spring Boot 默认的上传限制是 1MB。这个问题几乎百分之百会遇到源码交付时通常不会把上传限制调大因为本地测试用的小图够用。解决方式在application.yml的spring.servlet.multipart配置里把max-file-size改成 20MBmax-request-size改成 50MB。注意如果你用的是 Tomcat 8.5 以上版本还要看是不是有server.tomcat.max-swallow-size的限制某些版本下多个文件上传会因为 swallow 限制导致连接被重置这时候要把这个值也调大。5.4 现象运单列表页加载慢打开要好几秒运单列表慢是这个项目最容易踩的性能坑原因是运单表数据量一大t_waybill上的查询没有走到索引。源码里默认只在主键和一些业务唯一键上建了索引而列表页的查询条件通常是create_time范围、status状态、driver_id司机这三个字段的组合往往没有索引。解决方式是把列表页高频使用的过滤条件看一遍在 MySQL 里手工补索引ALTER TABLE t_waybill ADD INDEX idx_status_time (status, create_time); ALTER TABLE t_waybill ADD INDEX idx_driver_status (driver_id, status);这两个索引分别针对「按状态和创建时间过滤的调度列表」和「按司机和状态过滤的个人任务列表」。注意索引不是越多越好每个ALTER TABLE都会增加写入开销货运系统运单创建频繁索引只需要覆盖最高频的查询路径就够了。5.5 现象MyBatis-Plus 分页不生效返回全量数据货运系统的运单列表一定做了分页如果源码用的是 MyBatis-Plus分页插件不生效的低级错误很常见。典型现象是前端传了page1size10接口返回的记录数还是全部。原因是PaginationInnerInterceptor没有注册到 MyBatis-Plus 的配置里或者注册了但是被自定义的SqlSessionFactory覆盖了。启动时如果看到日志里没有PaginationInnerInterceptor相关的加载记录基本就是这个问题。解决方式是在配置类里显式添加拦截器Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); // 参数里的 DbType.MYSQL 指定数据库类型分页方言依赖这个参数 interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }这个配置的关键在于DbType.MYSQL必须匹配实际数据库。如果源码里写的是DbType.H2或者不传方言拦截器在某些版本下会静默失效既不分页也不报错排查起来非常消耗时间。另一个隐藏坑是分页插件和自定义 Mapper XML 里的LIMIT语句并存如果你改代码时在 XML 里手写了LIMIT同时又在 Service 层调了Page参数SQL 拼接后会出现重复LIMIT执行直接报错。这个问题的正确做法是分页统一由插件生成XML 里不要写死LIMIT。6. 从能跑到能用接口压测与索引优化的验证习惯源码跑通只是第一步真正上线前我习惯做两件事这两件事能让系统从「演示环境没问题」变成「业务高峰期扛得住」。第一件事是用压测工具给核心接口做一次快速压测不需要造大量数据就用 JMeter 或 Postman 的 Runner 给「创建运单」接口连续打 200 次请求观察耗时曲线和错误率。创建运单接口是货运系统的写入主链路它一慢整个调度业务都会卡住。压测前先把运单流水号生成逻辑确认一遍——如果源码里用了UUID.randomUUID()做主键业务号并发下不会冲突如果用时间戳加随机数那就要小心并发碰撞一旦撞号订单保存时会在唯一索引上抛异常压测结果会直接暴露这个问题。我一般会把业务号生成改成「日期 雪花ID后段」既保持可读性又彻底消除并发冲突。第二件事是给高频查询补索引重点观察两条 SQL。一条是运单列表页的查询条件通常是status和create_time另一条是结算统计的查询条件通常是customer_id和create_time。在压测之前用EXPLAIN看一下执行计划key列如果显示NULL说明全表扫描先把 5.4 里提到的组合索引补上再压测。补完索引后同一个接口的响应时间往往能降一个数量级这个改善在数据量只有几千条时感知不强但等运单涨到十万条以上效果就是秒开和一秒以内的差别。还有一个验证习惯值得保留每次改动数据库表结构或 Mapper XML 后重启项目并调用一次相关接口而不是只编译通过就完事。因为 MyBatis 的resultMap和 SQL 语句是运行时加载的编译通过不代表 SQL 能执行成功。用源码自带的前端页面走一遍「提单 → 派车 → 装货 → 签收 → 结算」的完整流程是最有说服力的回归测试。这套源码本质上是一个成熟业务骨架我从它身上学到最多的不是某个类怎么写而是运单状态机约束下的每个方法都有明确的调用边界。改它的时候守住状态机规则、用活 MyBatis 的日志、把索引补在该补的地方后面上生产就省心很多。希望这篇笔记能帮你的货运搬运项目少走几段弯路。本文还有配套的精品资源点击获取