简介专线物流系统是一套面向物流企业的Java综合解决方案覆盖订单管理、车辆调度、货物追踪、费用计算与报表分析等核心业务模块适合物流信息化开发者、企业技术团队用于二次开发或架构学习。压缩包共1028个文件约1.98MB主要包含Java源码、class编译文件、JSP页面、Spring/MyBatis相关XML配置、数据库脚本与设计文档各类型相互配套便于按模块查阅。已有193人学习下载。设计文档覆盖需求分析、模块划分、数据库设计及接口定义源码中可看到订单、调度、追踪等业务类的具体实现可直接复用业务逻辑、理解系统架构也可结合自身业务调整计费规则与流程是学习企业级Java项目组织的实用参考。1. 专线物流系统一张订单从揽收到签收代码和设计文档一起拆专线物流和快递网点的逻辑完全不同线路固定、班次固定、客户相对固定玩的是“从北京到上海这一条线上怎么把成本压到最低、时效做到最准”。这套专线物流系统Java技术栈带设计文档解决的问题就是把客户下单、揽收、干线运输、末端派送、签收回单这条链路用一套清晰的状态机和计费模型管起来让业务人员不用再靠Excel和微信对货。适合三类人做物流信息系统的开发、打算进TMS运输管理系统方向的新手以及需要给中小专线公司搭系统做参考的从业者。下面会从数据模型一直拆到调度和计费落地细节尽量都写出来。2. 核心数据模型从设计文档里抽出订单、运单、计费三张主表专线系统最忌讳一上来就建几十张表真正的骨架子就三张订单、运单、计费。加上轨迹表和车辆表辅助业务就能转起来。设计文档里这三张表的关系要理清楚一个订单可以被拆成一个或多个运单货太多一车装不下、或者分批次走一个运单经过多个轨迹节点计费则同时挂订单和运单。表职责和上下游的关系order_master客户委托和货物汇总一条订单可拆多条运单waybill实际运输单据关联订单、车辆、司机charge_item应收应付费用明细挂在订单和运单上2.1 订单表撑住“一票多件、一次委托”的业务形态下单是整条链路的起点。专线场景里客户可能一次报十几件货目的地是同一个城市的不同收货点所以订单表要同时挂货物汇总和收货地址信息。我一般建议订单表单独放“件数、总重量、总体积”不把每件货一条记录塞进订单表——明细拆到子表主表只在统计时用。CREATE TABLE order_master ( order_no VARCHAR(32) PRIMARY KEY COMMENT 订单号业务主键, customer_id BIGINT NOT NULL COMMENT 客户ID, line_code VARCHAR(32) NOT NULL COMMENT 线路编码如 BJ-SH, pickup_address VARCHAR(255) COMMENT 提货地址, delivery_address VARCHAR(255) COMMENT 默认送货地址, cargo_desc VARCHAR(255) COMMENT 货物品名摘要, package_qty INT NOT NULL DEFAULT 0 COMMENT 总件数, total_weight DECIMAL(10,2) DEFAULT 0 COMMENT 总重量单位kg, total_volume DECIMAL(10,2) DEFAULT 0 COMMENT 总体积单位m³, price_type TINYINT NOT NULL COMMENT 1按重量 2按体积 3按件数 4包车, expect_pickup_time DATETIME COMMENT 期望提货时间, expect_delivery_time DATETIME COMMENT 期望送达时间, order_status TINYINT NOT NULL DEFAULT 1 COMMENT 1待揽收 2已揽收 3配载中 4已发车 5在途 6到达分拨 7派送中 8已签收 9已回单 99异常, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;这里有个容易忽略的点order_no 用业务主键而不是自增ID因为订单号要打印在运单上、客户对账要拿着这个号来问自增ID暴露给外部后既难看又容易被遍历抓单。金额相关的信息我故意没放进主表因为计费可能要改价、要冲销放主表会让订单更新和费用更新互相锁真实项目里拆开更省心。2.2 运单与轨迹表状态机落库的正确姿势运单是真正跟着车走的单据。一个订单拆成多个运单时每个运单有自己的司机、车辆、发车时间所以状态机要落在运单上而不是订单上。这层拆不明白后面调度和计费全乱。CREATE TABLE waybill ( waybill_no VARCHAR(32) PRIMARY KEY, order_no VARCHAR(32) NOT NULL, vehicle_id BIGINT COMMENT 车辆ID, driver_id BIGINT COMMENT 司机ID, route_type TINYINT NOT NULL DEFAULT 2 COMMENT 2干线 1提货 3派送, load_weight DECIMAL(10,2) DEFAULT 0 COMMENT 实际装载重量kg, load_volume DECIMAL(10,2) DEFAULT 0 COMMENT 实际装载体积m³, plan_depart_time DATETIME COMMENT 计划发车时间, plan_arrive_time DATETIME COMMENT 计划到达时间, status TINYINT NOT NULL DEFAULT 1 COMMENT 1待装车 2在途 3到达 4已签收 99异常, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT运单表;轨迹表不用存太多字段关键是节点类型和时间要抓住揽收、发车、到达、派送、签收这几个时间节点后面算时效准时率、给客户截图证明都靠它。我见过有人把轨迹每条都设计成大宽表结果一个运单一千条轨迹查询越来越慢。正确做法是窄表每行一个节点事件按运单号和节点类型建索引即可。CREATE TABLE track_point ( id BIGINT AUTO_INCREMENT PRIMARY KEY, waybill_no VARCHAR(32) NOT NULL, node_type TINYINT NOT NULL COMMENT 1揽收 2发车 3到达 4派送 5签收, node_time DATETIME NOT NULL, location VARCHAR(255) COMMENT 节点位置, operator_id BIGINT COMMENT 操作人ID, KEY idx_waybill_node (waybill_no, node_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT轨迹节点表;2.3 计费表费用项拆分比想象中重要专线计费不是“总价一个数”客户问价时一定会拆“提货费、干线费、送货费、上楼费”。所以计费表要按费用项拆行并且区分应收向客户收和应付付给司机、付给承运商两条线不能混。CREATE TABLE charge_item ( charge_no VARCHAR(32) PRIMARY KEY, biz_type TINYINT NOT NULL COMMENT 1应收 2应付, order_no VARCHAR(32) COMMENT 订单号, waybill_no VARCHAR(32) COMMENT 运单号, fee_type VARCHAR(32) NOT NULL COMMENT 费用项TRANSPORT/PICKUP/DELIVERY/FUEL/OTHER, amount DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT 金额, calc_type TINYINT NOT NULL COMMENT 1按重量 2按体积 3按件数 4按车次, status TINYINT NOT NULL DEFAULT 0 COMMENT 0草稿 1已确认 2已开票 3已核销, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_biz_no (order_no, waybill_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT费用明细表;biz_type 和 fee_type 分开是这套设计里比较关键的点应收应付各自独立同一个订单可以有应收运费2000、应付司机1500中间500块就是利润。对账时直接按 biz_type 汇总不用在代码里区分。费用状态从草稿到核销也单独管避免订单还在途费用就已经确认了。这三张表的关系理清后整个系统的骨架就定了拿到代码后先把DDL和文档逐字段对一遍后面写业务逻辑才不用天天改表。3. 订单履约链路状态流转、费用拆分与对账逻辑怎么落代码有了表结构接下来是业务主链路。专线订单的履约不是一锤子买卖从下单到回单要跨好几天、经过好几手操作状态机设计得怎么样直接决定系统用起来顺不顺手。这一章把状态、费用、对账三件事串起来讲对应设计文档里最厚的那几节。3.1 状态机八个正常态加一个异常态的迁移规则订单状态设计成八个正常态加一个异常态。每两个状态之间的迁移都有一个前置条件比如“已发车”必须存在对应运单且运单状态为在途。状态迁移我一般用枚举加校验方法实现而不是散落在各种service里这样后人改流程时先看枚举就知道全局。public enum OrderStatus { WAIT_PICKUP(1, 待揽收), PICKED_UP(2, 已揽收), LOADING(3, 配载中), DEPARTED(4, 已发车), IN_TRANSIT(5, 在途), ARRIVED_HUB(6, 到达分拨), DELIVERING(7, 派送中), SIGNED(8, 已签收), RETURNED(9, 已回单), EXCEPTION(99, 异常处理); private final int code; private final String desc; public static OrderStatus of(int code) { for (OrderStatus s : values()) { if (s.code code) return s; } throw new IllegalArgumentException(未知状态: code); } public boolean canTransferTo(OrderStatus target) { // 允许回退的场景明确列出来比如派送中-异常 return switch (this) { case WAIT_PICKUP - target PICKED_UP || target EXCEPTION; case PICKED_UP - target LOADING || target EXCEPTION; case LOADING - target DEPARTED || target EXCEPTION; case DEPARTED - target IN_TRANSIT || target EXCEPTION; case IN_TRANSIT - target ARRIVED_HUB || target EXCEPTION; case ARRIVED_HUB - target DELIVERING || target EXCEPTION; case DELIVERING - target SIGNED || target EXCEPTION; case SIGNED - target RETURNED; default - false; }; } }这里最值得注意的就是“允许回退的场景明确列出来”这段注释。业务上会发生货到了客户拒收这时状态从派送中退回异常如果状态机写得过于严格业务人员只能找开发改库血泪经验。提示状态机的回退路径一定要在设计阶段就定义好等上线后再补业务人员会被憋得绕开系统打电话。所以设计文档里的状态图建议自己再过一遍把“哪些正常流、哪些回退流”都画到枚举注释里。3.2 费用引擎发车时重算签收后确认费用计算最忌“下单时就算死”。专线的实际重量往往和预报重量有出入到发车时过磅才能确定最终计费重量。所以我的习惯是下单生成草稿费用预收金额揽收或发车时按实际重量重新算一次签收后确认。这样客户看到的账单永远基于最新数据。Service public class ChargeService { public ChargeResult calcAndCreate(OrderMaster order) { // 先查客户合同价按客户线路起止时间匹配 ContractPrice price priceService.match(order.getCustomerId(), order.getLineCode(), LocalDate.now()); // 干线费重量价 or 体积价 or 件数价按价高者计 BigDecimal lineFee calcLineFee(order, price); // 提货费超过免费上门范围按趟收 BigDecimal pickupFee order.isNeedPickup() ? price.getPickupFee() : BigDecimal.ZERO; // 附加费上楼、等时、燃油单独计 BigDecimal extraFee calcExtraFee(order); return buildCharge(order, price, lineFee, pickupFee, extraFee); } }这段代码逻辑不复杂但参数含义要说清楚calcLineFee 里用的是“价高者计”这是专线行业常见默认规则因为一辆车占用的空间和重量都影响成本和利润只按重量算容易亏在轻泡货上。ContractPrice 的匹配维度是客户线路时间同一个客户不同月份价格可能不一样所以 match 方法要支持按价格版本生效日期筛选。价高者计不是销售口号是成本模型的底线。3.3 对账逻辑月结客户的对账单怎么生成专线的大客户基本是月结每个月生成对账单客户运营拿着单子和客户逐笔核对。对账单的设计原则是“一笔订单一行明细一个费用项一列金额”让客户能对着自己的发货记录查。系统里还要支持调价冲销比如客户说某票货破损赔偿直接在账上生成一笔负金额调整单而不是改原始费用记录这样审计时才能解释清楚。-- 月度对账查询按客户和账期汇总应收 SELECT DATE_FORMAT(create_time, %Y-%m) AS bill_month, order_no, customer_id, SUM(CASE WHEN fee_type TRANSPORT THEN amount ELSE 0 END) AS transport_fee, SUM(CASE WHEN fee_type PICKUP THEN amount ELSE 0 END) AS pickup_fee, SUM(CASE WHEN fee_type DELIVERY THEN amount ELSE 0 END) AS delivery_fee, SUM(CASE WHEN fee_type OTHER THEN amount ELSE 0 END) AS other_fee, SUM(amount) AS total_fee FROM charge_item WHERE biz_type 1 AND status 1 AND create_time BETWEEN #{startTime} AND #{endTime} GROUP BY bill_month, order_no, customer_id ORDER BY order_no;这条SQL有几个点容易翻车biz_type 必须限定为1应收否则应付也会被人为统计进去status 限定为已确认以上草稿费用不能进对账单。GROUP BY 里带了 order_no 和 customer_id目的是对账单能按客户筛选又能按订单逐行核对。如果你在真实项目里发现对账有差异九成是这两个条件没加全。4. 运力调度与配载把一车货凑够再发专线的成本大头是干线运输一辆17.5米的车从北京开到上海无论装一半还是装满油费过路费几乎一样所以调度的核心目标就一个把同一条线、同一天出发的货尽可能装满。装不装满直接决定这趟车是赚钱还是亏钱。4.1 配载聚合按线路、按日期、按装载约束聚单调度员打开界面的第一眼应该是“今天BJ-SH线还有多少票待配载”而不是一个个订单翻。配载算法要做的事情是把待配载订单按线路分组然后计算当前已配载重量和体积剩余多少舱位由可用运力决定。-- 待配载订单聚合查询 SELECT o.line_code, o.expect_pickup_time, COUNT(*) AS order_cnt, SUM(o.package_qty) AS total_pieces, SUM(o.total_weight) AS total_weight, SUM(o.total_volume) AS total_volume FROM order_master o JOIN vehicle v ON v.line_code o.line_code AND v.plan_depart_date DATE(o.expect_pickup_time) AND v.status READY WHERE o.order_status 3 -- 已揽收待配载 GROUP BY o.line_code, o.expect_pickup_time HAVING total_weight 0 OR total_volume 0;这条查询的 JOIN 条件里带上了车辆可用状态只统计有车可装的线路避免调度员看到有货没车的空欢喜。order_status 3 是“已揽收待配载”也就是说配载必须在揽收之后货物实际到手才能算数报重报轻在这里是调度最头疼的事。4.2 装车判断重量和体积双重校验0.9安全系数装车不只是“总重量不超载”那么简单。17.5米厢车额定载重是30吨左右容积约120方但货物之间的空隙、不能叠压的货都会让实际可装载量打折。我一般用两个系数做折扣装载率安全系数0.9混装系数看货物类型。public boolean canLoad(LoadPlan plan, OrderMaster newOrder) { BigDecimal maxWeight plan.getVehicle().getMaxWeight().multiply(new BigDecimal(0.9)); BigDecimal maxVolume plan.getVehicle().getMaxVolume().multiply(new BigDecimal(0.9)); BigDecimal weightAfter plan.getLoadedWeight().add(newOrder.getTotalWeight()); BigDecimal volumeAfter plan.getLoadedVolume().add(newOrder.getTotalVolume()); // 两个条件要同时满足只看重量会爆仓 if (weightAfter.compareTo(maxWeight) 0) { return false; } if (volumeAfter.compareTo(maxVolume) 0) { return false; } return true; }重量体积双重校验这段逻辑很简单但常被漏掉的是“0.9安全系数”不是拍脑袋装车时托盘之间必须留叉车作业空间而且预报重量普遍偏轻留10%余量是行业惯例。如果你做的是冷链或危险品专线这个系数要调得更保守。只看重量不看体积是配载翻车最多的原因。4.3 运力扣减条件更新防两个调度员抢同一辆车配载的最后一步是把订单绑定到运单并扣减车辆剩余舱位。这一步要防并发两个调度员同时看中同一台车如果都点确认超卖就发生了。解决方案是数据库条件更新用剩余舱位本身作为乐观锁条件。UPDATE vehicle SET loaded_weight loaded_weight #{weight}, loaded_volume loaded_volume #{volume}, version version 1 WHERE vehicle_id #{vehicleId} AND status READY AND loaded_weight #{weight} max_weight * 0.9 AND loaded_volume #{volume} max_volume * 0.9;这段SQL把业务校验下沉到数据库层面update返回的影响行数为1才代表扣减成功为0则说明有人已经抢先把舱位占了。应用层判断受影响行数后要么提示调度员换车要么重新查一次剩余舱位。比在Java里先select再update安全得多因为两条并发事务可能都读到同一个旧值。配载这块整体不复杂真正难的是业务规则的穷举哪些货不能压、哪些客户要求必须直达、时效件要不要单独留位。设计文档里如果列了规则清单建议优先看那一节。5. 专线物流系统避坑指南五个翻车场景与修复方案这一章是实打实的踩坑记录。我拆过不止一套物流系统凡是生产环境出问题的基本都集中在下面五个场景每个都是先复现现象、再讲原因、最后给解决方案。5.1 重复计费一票货算了两遍钱现象对账时发现某客户当月账单里有一票货出现两次金额完全一样。原因揽收和发车两个动作都会触发费用重算重算逻辑没有做幂等消息队列消费失败重试时又把同一单据消费了一次。解决给费用表加唯一业务键比如 order_no fee_type version重复插入直接报错应用捕获异常后改为更新。或者更简单在重算前先按业务键查一次是否已生成本期费用已存在则只更新不新增。幂等这事不做线上迟早要出一次重复账。5.2 状态回跳货到了分拨站系统却退回在途现象运单状态从“到达分拨”被改成“在途”前端显示和实际不符客户投诉时效不准。原因司机App上报位置是异步的多条消息到达后端时顺序错乱旧消息后到把新状态覆盖了。解决状态更新必须带版本号或校验“只允许向后流转”Java代码里用 update ... where status 旧状态 这样的乐观锁更新行数为0就丢弃这条消息。我在这类系统里见过最省事的方案是直接在更新语句里写死“新状态编码必须大于旧状态编码”基本能挡住九成乱序消息。5.3 大客户对账不平账单和客户的台账差几十块现象月结对账单导出后客户说金额不对一查是合同价已经调整但系统里生成的费用还是按旧价格算的。原因费用生成时快照了价格但合同变更后没有对已生成未确认的费用做重算。解决合同价格表按版本存放生效日期和失效日期必填费用生成时记录 price_version_id每月对账前跑一个“调价影响重算任务”把未确认费用按最新版本重算同时生成差价调整单。黑匣子最容易出现在这里客户说多少就是多少的日子该结束了。5.4 运力超卖同一票货出现在两个运单里现象同一票货出现在两个运单里仓库发货时才发现货不够分。原因两个调度员同时操作先查剩余舱位足够再点确认两笔事务都读到空位后提交的覆盖了先提交的。解决用第四章的条件更新方式扣减舱位应用层根据 update 影响行数做二次判断。这是典型的并发问题别写select再update也别指望加锁——行锁在跨服务调用场景里根本锁不住。5.5 设计文档与代码脱节字段名对不上一编译就挂现象数据库里多了一个字段设计文档还是旧的新来的同事对着文档写代码字段名对不上编译直接挂。原因文档更新流程缺失开发只改代码不回头改文档。解决拿到这套资源后第一件事就是把DDL和设计文档的字段清单做一次 diff不一致的先手工对齐然后约定后面每次表结构变更都登记在变更记录页。这不是技术问题是流程习惯但比任何技术坑都容易反复踩。6. 让系统真正跑起来最小闭环验证与三个提效习惯代码到手先别急着看业务细节花半天把基础环境拉起跑通一条最小链路比通读所有代码效率都高。我拿到这套专线物流项目时第一件事是起一个Spring Boot实例配上MySQL和Redis然后从下单接口一路调到生成对账单。6.1 最小闭环四个接口串起核心链路最小闭环要覆盖的接口就四个创建订单、订单转已揽收、配载生成运单、签收并生成应收费用。把这四个接口串起来跑通订单从客户侧走到财务侧的核心链路就全部验证了。我在本地跑这套流程时习惯用Postman存一份环境变量订单号自动传给下一个请求一轮跑完大约十分钟比打开前端页面点来点去快得多。6.2 用一段脚本把状态机跑一遍public static void main(String[] args) { OrderStatus status OrderStatus.WAIT_PICKUP; ListOrderStatus flow List.of( OrderStatus.WAIT_PICKUP, OrderStatus.PICKED_UP, OrderStatus.LOADING, OrderStatus.DEPARTED, OrderStatus.IN_TRANSIT, OrderStatus.ARRIVED_HUB, OrderStatus.DELIVERING, OrderStatus.SIGNED, OrderStatus.RETURNED ); for (int i 0; i flow.size() - 1; i) { if (!flow.get(i).canTransferTo(flow.get(i 1))) { throw new IllegalStateException(非法流转: flow.get(i) - flow.get(i 1)); } } System.out.println(状态机主流程校验通过); }这段脚本把主流程从待揽收一路走到已回单逐个校验相邻状态的迁移合法性。实际开发时还能往里加异常回退路径的用例。跑脚本比手动点界面快得多适合每次改完状态机逻辑后回归。6.3 三个提效习惯规范检查、代码补全、示例代码当规格第一个习惯是拿到代码先跑一次规范检查。Java项目里常见的 checkstyle 或 sonar 配置跑一遍不光是格式问题还能提前找出资源没关闭、空指针隐患这类问题。第二个习惯是重度使用 IDE 的代码补全和生成器把设计文档里的字段列表直接粘成实体类比手工敲减少一半出错率。第三个习惯是把示例代码当规格说明看项目里的示例代码写清了接口的调用顺序和参数含义遇到看不懂的业务字段先搜示例代码通常比直接翻实现类快。注意跑规范检查时别只看 error 级别warning 级别的空指针隐患在物流这类并发场景里才是最致命的。说句实话状态机和计费这两块是我每次拆物流项目都最紧张的部分它们决定了系统到底是一套能用的工具还是一个演示Demo。从那以后我每次拿新项目都强制自己先用最小闭环把这两块走一遍再看别的模块。希望帮到你。本文还有配套的精品资源点击获取