企业官网建设流程全解析

最近国企自营网约车平台上线的消息引发了不少讨论，司机直招、抽成更低成为核心卖点。作为后端开发者，我们在关注市场变化的同时，更应该思考一个问题：如果让你从零搭建一个自营网约车平台，核心的司机审核、计价、抽成、派单模块到底怎么设计？本文不讨论商业竞争，只做技术拆解，从业务架构、数据库设计、核心代码实现到常见排错，完整梳理一套可落地的思路。

1. 背景与核心概念

1.1 国企自营网约车平台的技术关注点

网约车平台的本质是“撮合交易”：乘客发单、司机接单、平台完成匹配并抽取服务费。但“自营”两个字意味着平台不只是信息中介，而是需要直接管理运力、制定服务标准、审核司机资质、承担运营责任。

从技术侧看，这种模式有几个明显的特点：

• 司机直接与平台签约，入驻审核、每日安全监测、资质复审都必须在系统内闭环。
• 平台直接制定计价规则和抽成比例，抽成低意味着计费和分账模块需要非常精细，不能出现算错、漏算、结算延迟。
• 订单量可能集中在特定区域，派单逻辑需要兼顾距离、驾驶员状态、实时路况。
• 数据合规要求高，司机身份证、驾驶证、行驶证、人脸识别信息都属于敏感数据，必须加密存储，权限严格控制。

所以，国企自营网约车平台绝对不是“做一个打车App”那么简单。小程序、乘客端、司机端、管理后台、风控系统、财务结算系统，每一块都需要独立设计，再通过接口串联。

1.2 与传统平台的差异

传统C2C模式下，平台以“轻资产运营”为主，司机注册后可快速上线，算法重点在供需匹配。自营模式下，系统更像“自营电商平台 + 运力管理系统”的结合体：

从开发角度看，最值得研究的是司机审核流程、计价抽成计算、派单调度这三个核心模块。下面分别展开。

2. 环境准备与项目结构

2.1 技术选型

为了便于演示，本文以 Java 技术栈为例，使用 Spring Boot 构建核心服务。你可以在本地搭建一个精简版的自营网约车平台后端，跑通“司机入驻 -> 平台审核 -> 乘客下单 -> 计费抽成 -> 司机结算”这条主链路。

示例环境：

• 操作系统：Windows 10 / macOS / Linux 均可
• JDK：1.8 或 11
• 构建工具：Maven 3.6+
• 框架：Spring Boot 2.7.x
• 数据库：MySQL 5.7 或 8.0
• ORM：MyBatis-Plus 3.5.x
• 缓存：Redis 6.x（用于派单和会话管理）
• IDE：IntelliJ IDEA / Eclipse
• 接口测试工具：Postman / Apifox

版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。

2.2 项目模块划分

一个完整的网约车平台通常拆成多个微服务，但本地演示可以把服务合并为一个 Spring Boot 项目，通过包结构区分业务模块。

ride-hailing-platform/ ├── pom.xml └── src/main/java/com/example/ridehailing/ ├── RideHailingApplication.java ├── config/ │ └── CommissionConfig.java # 抽成配置读取类 ├── controller/ │ ├── DriverController.java # 司机端接口 │ ├── OrderController.java # 乘客端订单接口 │ └── SettlementController.java # 结算接口 ├── service/ │ ├── DriverService.java # 司机入驻与审核 │ ├── OrderService.java # 订单业务 │ ├── SettlementService.java # 司机结算 │ ├── CommissionCalculator.java # 抽成计算器 │ └── DispatchService.java # 派单服务 ├── entity/ │ ├── Driver.java │ ├── DriverReviewRecord.java │ ├── OrderInfo.java │ └── SettlementRecord.java └── mapper/ ├── DriverMapper.java ├── OrderMapper.java └── SettlementMapper.java

2.3 数据库表设计

核心表如下：

-- 司机信息表 CREATE TABLE t_driver ( id BIGINT PRIMARY KEY AUTO_INCREMENT, driver_name VARCHAR(32) NOT NULL COMMENT '司机姓名', phone VARCHAR(20) NOT NULL COMMENT '手机号', id_card VARCHAR(32) NOT NULL COMMENT '身份证号（加密存储）', license_no VARCHAR(32) NOT NULL COMMENT '驾驶证号', plate_no VARCHAR(16) NOT NULL COMMENT '车牌号', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待审核 1已通过 2已驳回 3冻结', audit_time DATETIME DEFAULT NULL COMMENT '审核时间', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_phone (phone), UNIQUE KEY uk_id_card (id_card) ) COMMENT '网约车司机表'; -- 司机审核记录表 CREATE TABLE t_driver_review_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, driver_id BIGINT NOT NULL, review_status TINYINT NOT NULL COMMENT '1通过 2驳回', review_remark VARCHAR(255) COMMENT '审核备注', reviewer VARCHAR(32) COMMENT '审核人', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT '司机审核记录表'; -- 订单表 CREATE TABLE t_order_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '订单号', passenger_phone VARCHAR(20) NOT NULL, driver_id BIGINT DEFAULT NULL COMMENT '接单司机ID', start_longitude DECIMAL(10,6) NOT NULL, start_latitude DECIMAL(10,6) NOT NULL, end_longitude DECIMAL(10,6), end_latitude DECIMAL(10,6), distance_km DECIMAL(10,2) DEFAULT 0 COMMENT '实际里程', duration_min INT DEFAULT 0 COMMENT '实际时长（分钟）', order_status TINYINT NOT NULL DEFAULT 0 COMMENT '0待接单 1已接单 2行程中 3已完成 4已取消', amount DECIMAL(10,2) DEFAULT 0 COMMENT '订单金额', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, end_time DATETIME DEFAULT NULL ) COMMENT '订单表'; -- 司机结算记录表 CREATE TABLE t_settlement_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, driver_id BIGINT NOT NULL, order_amount DECIMAL(10,2) NOT NULL COMMENT '订单金额', commission_rate DECIMAL(5,2) NOT NULL COMMENT '抽成比例，比如18.00表示18%', commission_amount DECIMAL(10,2) NOT NULL COMMENT '平台抽成金额', driver_amount DECIMAL(10,2) NOT NULL COMMENT '司机到手金额', settle_status TINYINT NOT NULL DEFAULT 0 COMMENT '0待结算 1已结算', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, settle_time DATETIME DEFAULT NULL ) COMMENT '司机结算记录表';

如果生产环境要接财务系统，通常还需要分账流水表、提现记录表、发票表等，本文先聚焦核心链路。

3. 核心模块一：司机直招与入驻审核

3.1 业务流程拆解

“司机自招”从系统角度理解，就是司机注册入驻时，由平台审核人员介入，而不是完全依赖算法自动通过。业务流程如下：

1. 司机提交姓名、手机号、身份证号、驾驶证号、车牌号。
2. 系统校验手机号是否唯一、身份证格式是否正确。
3. 自动调用第三方实名认证接口，核验身份信息。
4. 进入人工审核队列，审核员查看材料后通过或驳回。
5. 审核通过后，司机状态变为可用，可以接单。

这个流程的关键点在于：实名认证结果不能直接等于“入驻成功”，保存审核记录，保留人工复核能力，方便后续追溯。

3.2 代码实现：司机申请入驻

// 文件路径：src/main/java/com/example/ridehailing/service/DriverService.java @Service public class DriverService { @Resource private DriverMapper driverMapper; @Resource private DriverReviewRecordMapper reviewRecordMapper; /** * 司机提交入驻申请 */ @Transactional(rollbackFor = Exception.class) public Long applyDriver(DriverApplyDTO dto) { // 1. 手机号唯一性校验 Long count = driverMapper.selectCount( new LambdaQueryWrapper<Driver>() .eq(Driver::getPhone, dto.getPhone())); if (count > 0) { throw new BizException("手机号已注册"); } // 2. 身份证格式简单校验 if (!dto.getIdCard().matches("\\d{17}[0-9Xx]")) { throw new BizException("身份证格式不正确"); } // 3. 构建司机实体，状态为待审核 Driver driver = new Driver(); driver.setDriverName(dto.getDriverName()); driver.setPhone(dto.getPhone()); // 生产环境这里必须加密存储，使用AES或国密算法 driver.setIdCard(AesUtil.encrypt(dto.getIdCard())); driver.setLicenseNo(dto.getLicenseNo()); driver.setPlateNo(dto.getPlateNo()); driver.setStatus(0); driverMapper.insert(driver); // 4. 记录申请动作 DriverReviewRecord record = new DriverReviewRecord(); record.setDriverId(driver.getId()); record.setReviewStatus(0); record.setReviewRemark("司机提交入驻申请"); reviewRecordMapper.insert(record); return driver.getId(); } }

这里需要说明几点：

• @Transactional保证司机信息和审核记录要么同时写入，要么同时回滚，避免数据不一致。
• 身份证属于敏感个人信息，必须加密存储，不能用明文。
• 后续第三方实名认证接口返回后，需要更新审核记录。

3.3 代码实现：人工审核通过

/** * 审核通过司机申请 */ @Transactional(rollbackFor = Exception.class) public void approveDriver(Long driverId, String reviewer) { // 1. 校验司机存在且为待审核状态 Driver driver = driverMapper.selectById(driverId); if (driver == null) { throw new BizException("司机不存在"); } if (driver.getStatus() != 0) { throw new BizException("当前状态不可审核"); } // 2. 更新司机状态 Driver update = new Driver(); update.setId(driverId); update.setStatus(1); update.setAuditTime(new Date()); driverMapper.updateById(update); // 3. 写审核记录 DriverReviewRecord record = new DriverReviewRecord(); record.setDriverId(driverId); record.setReviewStatus(1); record.setReviewRemark("人工审核通过"); record.setReviewer(reviewer); reviewRecordMapper.insert(record); }

同样的，驳回操作就是把状态改为 2，并写驳回原因。所有审核操作都要留痕，这是自营平台合规运营的基本要求。

4. 核心模块二：低抽成计费与司机收入结算

4.1 计价模型设计

“抽成更低”在技术上如何实现？答案是把抽成比例做成可配置项，而不是写死在代码里。

计价模型通常包含：

• 起步价
• 里程单价（元/公里）
• 时长单价（元/分钟）
• 夜间服务费、远途费、动态调价系数

简化后的计算公式：

基础费用 = 起步价 + 里程单价 * 里程 + 时长单价 * 时长 动态系数 = 根据供需情况生成，一般在 1.0 到 2.0 之间 订单金额 = 基础费用 * 动态系数 平台抽成 = 订单金额 * 抽成比例 司机收入 = 订单金额 - 平台抽成 - 信息服务费

4.2 配置类：抽成比例可配置

// 文件路径：src/main/java/com/example/ridehailing/config/CommissionConfig.java @Component @ConfigurationProperties(prefix = "platform.commission") @Data public class CommissionConfig { /** * 默认抽成比例，例如 15 表示 15% */ private BigDecimal defaultRate = new BigDecimal("15"); /** * 信息服务费，单位：元 */ private BigDecimal serviceFee = new BigDecimal("0.5"); /** * 起步价，单位：元 */ private BigDecimal basePrice = new BigDecimal("8.00"); /** * 里程单价，单位：元/公里 */ private BigDecimal perKmPrice = new BigDecimal("1.80"); /** * 时长单价，单位：元/分钟 */ private BigDecimal perMinutePrice = new BigDecimal("0.30"); }

在application.yml中配置：

platform: commission: default-rate: 15 service-fee: 0.5 base-price: 8.00 per-km-price: 1.80 per-minute-price: 0.30

好处是：当业务方决定降低抽成时，运维只需要改配置并重启服务，不需要改代码。生产环境中，这类配置还可以接入配置中心，实现动态刷新。

4.3 抽成计算器

// 文件路径：src/main/java/com/example/ridehailing/service/CommissionCalculator.java @Component public class CommissionCalculator { /** * 计算订单金额和司机收入 */ public SettlementResult calculate(BigDecimal distanceKm, Integer durationMin, CommissionConfig config) { // 1. 计算基础费用 BigDecimal baseAmount = config.getBasePrice() .add(config.getPerKmPrice().multiply(distanceKm)) .add(config.getPerMinutePrice().multiply(BigDecimal.valueOf(durationMin))); // 2. 四舍五入保留两位小数 BigDecimal orderAmount = baseAmount.setScale(2, RoundingMode.HALF_UP); // 3. 计算平台抽成 BigDecimal commissionRate = config.getDefaultRate() .divide(BigDecimal.valueOf(100), 4, RoundingMode.HALF_UP); BigDecimal commissionAmount = orderAmount .multiply(commissionRate) .setScale(2, RoundingMode.HALF_UP); // 4. 计算司机到手收入 BigDecimal driverAmount = orderAmount .subtract(commissionAmount) .subtract(config.getServiceFee()) .setScale(2, RoundingMode.HALF_UP); return new SettlementResult(orderAmount, commissionRate, commissionAmount, driverAmount); } }

为什么不直接写orderAmount * 0.15？因为小数乘法在计算机中容易产生精度问题。用BigDecimal时也要注意，divide必须指定精度和舍入模式，否则可能抛ArithmeticException。

4.4 订单完成后的结算逻辑

// 文件路径：src/main/java/com/example/ridehailing/service/SettlementService.java @Service public class SettlementService { @Resource private SettlementMapper settlementMapper; @Resource private OrderMapper orderMapper; @Resource private CommissionCalculator calculator; @Resource private CommissionConfig commissionConfig; /** * 订单完成后触发结算 */ @Transactional(rollbackFor = Exception.class) public Long settleOrder(String orderNo) { // 1. 查询订单 OrderInfo order = orderMapper.selectOne( new LambdaQueryWrapper<OrderInfo>() .eq(OrderInfo::getOrderNo, orderNo)); if (order == null) { throw new BizException("订单不存在"); } if (order.getOrderStatus() != 3) { throw new BizException("订单未完成，不能结算"); } // 2. 防止重复结算 Long settleCount = settlementMapper.selectCount( new LambdaQueryWrapper<SettlementRecord>() .eq(SettlementRecord::getOrderNo, orderNo)); if (settleCount > 0) { throw new BizException("该订单已结算"); } // 3. 计算金额 SettlementResult result = calculator.calculate( order.getDistanceKm(), order.getDurationMin(), commissionConfig ); // 4. 保存结算记录 SettlementRecord record = new SettlementRecord(); record.setOrderNo(orderNo); record.setDriverId(order.getDriverId()); record.setOrderAmount(result.getOrderAmount()); record.setCommissionRate(result.getCommissionRate()); record.setCommissionAmount(result.getCommissionAmount()); record.setDriverAmount(result.getDriverAmount()); record.setSettleStatus(0); settlementMapper.insert(record); return record.getId(); } }

这里最容易被忽略的是“幂等性”。如果订单完成回调接口被重复调用，没有幂等保护就可能生成两条结算记录，导致司机多收钱、平台多扣钱。上例通过settleCount > 0做了基础防重，生产环境还会加唯一索引兜底。

4.5 抽成比例如何做到更低更灵活

低抽成不只是改一个数字，还可以设计更精细的规则：

• 接单时长抽成：司机在高峰时段完成订单，抽成降低。
• 订单金额区间抽成：小额订单抽成低，大额订单抽成高。
• 司乘评分抽成：高评分司机享受低抽成。

这些规则落到代码里就是“抽成策略模式”：

public interface CommissionStrategy { BigDecimal getRate(OrderInfo order, Driver driver); } @Component public class HighScoreStrategy implements CommissionStrategy { @Override public BigDecimal getRate(OrderInfo order, Driver driver) { // 司机评分大于4.8，抽成降低3个点 if (driver.getScore() >= 4.8) { return new BigDecimal("12"); } return new BigDecimal("15"); } }

实际项目中，这些策略会通过配置中心动态下发，业务调整不需要发版。

5. 核心模块三：订单派单与调度

5.1 派单策略

自营平台车辆属于平台统一管理，派单算法可以更直接。最简单的策略是“就近派单”：乘客下单后，找到距起点最近且状态为空的司机，把订单推送过去。

高级一点的策略会综合以下维度：

• 距离（直线距离或导航距离）
• 司机服务分
• 司机当前朝向
• 预估到达时间
• 区域热度均衡

示例中先实现一个简单的“半径扫描 + 最近司机”逻辑，便于理解整体链路。

5.2 派单服务实现

// 文件路径：src/main/java/com/example/ridehailing/service/DispatchService.java @Service public class DispatchService { @Resource private OrderMapper orderMapper; @Resource private DriverLocationMapper locationMapper; /** * 简化的就近派单：扫描乘客起点附近3公里内的空闲司机 */ public Long dispatch(Long orderId, BigDecimal startLng, BigDecimal startLat) { // 1. 查询订单 OrderInfo order = orderMapper.selectById(orderId); if (order == null || order.getOrderStatus() != 0) { throw new BizException("订单不可派单"); } // 2. 查找附近可用司机（简化SQL，生产环境使用GEO索引或Redis GEO） List<DriverLocation> drivers = locationMapper.findNearbyIdleDrivers( startLng, startLat, 3.0); if (CollectionUtils.isEmpty(drivers)) { throw new BizException("附近暂无可用司机"); } // 3. 简单选择距离最近的司机 drivers.sort(Comparator.comparing(DriverLocation::getDistance)); DriverLocation target = drivers.get(0); // 4. 更新订单接单司机和状态 OrderInfo update = new OrderInfo(); update.setId(orderId); update.setDriverId(target.getDriverId()); update.setOrderStatus(1); orderMapper.updateById(update); return target.getDriverId(); } }

对应的 Mapper SQL 可以参考下面的写法：

<select id="findNearbyIdleDrivers" resultType="DriverLocation"> SELECT driver_id, longitude, latitude, ST_Distance_Sphere( POINT(#{lng}, #{lat}), POINT(longitude, latitude) ) / 1000 AS distance FROM t_driver_location WHERE driver_status = 1 HAVING distance &lt;= #{radiusKm} ORDER BY distance ASC LIMIT 10 </select>

生产环境不建议用全表扫描。如果数据量大，可以使用 Redis GEO 存储司机经纬度，或者使用 MySQL 8.0 的空间索引，再或者引入 Elasticsearch / MongoDB 的地理查询能力。

5.3 并发派单的坑

当多个订单同时匹配同一个司机时，会出现“重复派单”问题。解决方式有两种：

• 数据库乐观锁：更新司机状态时加上WHERE driver_status = 1，更新影响行数为 0 表示司机已被抢走。
• Redis 分布式锁：按driver:{driverId}加锁，避免并发修改。

推荐先用简单的状态条件更新，业务量上来后再引入分布式锁。避免一上来就造复杂轮子。

6. 完整实战：跑通入驻到结算主链路

6.1 创建启动类

// 文件路径：src/main/java/com/example/ridehailing/RideHailingApplication.java @SpringBootApplication @MapperScan("com.example.ridehailing.mapper") public class RideHailingApplication { public static void main(String[] args) { SpringApplication.run(RideHailingApplication.class, args); } }

6.2 司机入驻接口测试

启动项目后，使用 Postman 调用：

POST /api/driver/apply Content-Type: application/json { "driverName": "张三", "phone": "13800138000", "idCard": "110101199001011234", "licenseNo": "BJ110101202301234", "plateNo": "京A12345" }

预期返回：

{ "code": 0, "message": "success", "data": 1 }

随后管理员调用审核接口：

POST /api/driver/approve?driverId=1&reviewer=admin

6.3 订单计价与结算测试

模拟一个订单，距离 12 公里，时长 25 分钟。按默认配置计算：

• 起步价：8.00
• 里程费：12 * 1.80 = 21.60
• 时长费：25 * 0.30 = 7.50
• 订单金额 = 8.00 + 21.60 + 7.50 = 37.10
• 平台抽成 = 37.10 * 15% = 5.57
• 司机收入 = 37.10 - 5.57 - 0.50 = 31.03

调用接口后，数据库消费结算记录表会插入一条完整数据。这些结果可以在控制台日志中看到，也可以通过接口返回。

6.4 完整示例代码结构回顾

以上核心代码已经覆盖了：

• 司机入驻
• 资料审核
• 订单创建
• 派单
• 订单完成
• 计费抽成
• 司机结算

你可以把上述代码组合到一个 Spring Boot 项目中，自行用 controller 暴露接口，跑通一条边到边的业务流。Controller 层相对简单，这里给一个示例：

// 文件路径：src/main/java/com/example/ridehailing/controller/DriverController.java @RestController @RequestMapping("/api/driver") public class DriverController { @Resource private DriverService driverService; @PostMapping("/apply") public Result<Long> apply(@RequestBody DriverApplyDTO dto) { return Result.success(driverService.applyDriver(dto)); } @PostMapping("/approve") public Result<Void> approve(@RequestParam Long driverId, @RequestParam String reviewer) { driverService.approveDriver(driverId, reviewer); return Result.success(); } }

7. 常见问题与排查思路

7.1 司机审核状态一直不变

7.2 结算金额与手工计算不一致

这通常是 BigDecimal 使用不规范导致的。常见错误：

// 错误示例：直接使用 double 计算金额 double amount = distance * 1.8 + duration * 0.3;

正确的做法是全程使用BigDecimal，并且在divide时指定精度和舍入模式。如果金额仍然不对，建议在结算前打印所有入参和中间结果，逐项核对。

7.3 数据库死锁

如果多个订单同时结算，并且结算涉及司机余额、订单状态、结算记录三张表，不同事务的更新顺序不一致就会产生死锁。

解决思路：

• 统一更新顺序，先更新订单，再写结算记录。
• 减少事务范围，不要在事务中调用远程接口。
• 给结算表加唯一索引，防止并发插入同一订单。

7.4 派单时司机被重复指派

前面提到过，最稳妥的防重做法是“条件更新”：

int rows = driverMapper.updateStatus(driverId, 0, 1); if (rows == 0) { throw new BizException("司机已被抢单"); }

这条 SQL 的意思是：只有当司机当前状态是 0（空闲）时，才能更新为 1（已接单）。如果更新行数为 0，说明司机已经被其他订单锁定。

7.5 测试环境一切正常，生产环境偶发超时

本地测试量小，不会暴露问题。生产环境出现偶发超时的排查顺序建议为：

1. 先看数据库慢查询日志，确认是否出现全表扫描。
2. 再看 Redis 缓存命中率，确认派单热点数据是否大量回源。
3. 看服务调用链路，确认第三方实名认证接口或支付回调是否有超时重试，导致线程阻塞。
4. 最后看 GC 日志，排除频繁 Full GC 导致的服务停顿。

8. 最佳实践与工程建议

8.1 敏感数据加密与脱敏

司机身份证、驾驶证、手机号都属于敏感个人信息。建议：

• 数据库存储密文，使用 AES-128/256 或国密 SM4。
• 日志打印时脱敏，只展示前三位和后四位。
• 后台查询接口提供脱敏字段，导出文件也做脱敏处理。
• 对接第三方实名认证时，最小化传递信息，避免完整身份证出现在请求日志中。

8.2 金额计算统一用分存储

如果不想被 BigDecimal 的精度问题反复折磨，可以统一用“分”作为金额单位存储。

// 订单金额 37.10 元，存储为 3710 分 private Long amountInCent;

展示时再除以 100 转为元。这样可以避免浮点误差，也方便后续接入支付系统。缺点是需要统一约定，一旦某个接口漏转换就会出问题。

8.3 结算与提现的幂等设计

资金相关模块必须做到接口幂等：

• 每个订单只允许生成一次结算记录。
• 提现请求必须有业务流水号。
• 回调通知必须支持重试，并且重复通知不会导致重复入账。
• 对账程序定期比对“订单表金额汇总”和“结算表金额汇总”，发现差异立即告警。

8.4 配置与发布管理

抽成比例、计价规则这类运营配置，强烈建议放到配置中心（如 Apollo、Nacos），不要写在本地配置文件里。

好处很明显：

• 配置修改无需发版。
• 支持灰度发布，先让少量司机生效。
• 有历史版本记录，出问题可以快速回滚。
• 配置变更通知可以触发缓存刷新。

8.5 派单与订单状态机

订单状态变化建议用状态机管理，避免出现“已取消的订单又被接单”这类脏数据。

简单状态机如下：

待接单 -> 已接单 -> 行程中 -> 已完成 ↑ | | | v v | 已取消 已取消 +---------------------+

在代码里可以用一个专门的枚举类管理状态流转合法性：

public enum OrderStatus { PENDING(0), ACCEPTED(1), ONGOING(2), FINISHED(3), CANCELED(4); }

每次更新前检查前置状态，非法流转直接拒绝。

8.6 生产环境上线前的自检清单

如果你要把这套系统部署到生产环境，建议先过一遍下面这些问题：

• 计价配置是否已确认？抽成比例是否正确？
• 司机实名认证接口是否已联调？
• 身份证、手机号是否加密存储？
• 后台操作日志是否完整？
• 结算表是否有唯一索引？
• 是否做了超时重试和幂等处理？
• 是否有资金对账任务？
• 数据库是否做了主从备份？
• 业务高峰期流量预估是否完成？
• 乘客端和司机端的接口权限是否做了隔离？

这些问题越早想清楚，上线后踩的坑就越少。

8.7 常见的技术扩展方向

如果后续要优化这个系统，可以从以下几个方向深入：

• 派单算法升级：引入预估到达时间、司机意愿度、区域供需热度。
• 多级缓存设计：热区司机地理位置用 Redis GEO，订单状态用本地缓存 + Redis。
• 消息队列解耦：订单完成、结算、分账通过 RocketMQ / Kafka 异步处理，降低接口延迟。
• 大数据风控：通过设备指纹、行为序列识别刷单和代驾行为。
• 灰度发布：司机端新版本先给少量司机使用，观察数据再全量。

下次你再看到“国企自营网约车平台上线”这类新闻时，可以顺着“司机审核、计价抽成、派单调度、资金结算”这条主线去理解背后的系统设计，技术实现的核心其实都是这些基础模块的叠加和工程化打磨。