网约车抽成比例下调：规则引擎如何支撑计费系统灵活调整

最近不少城市都在讨论网约车平台下调抽成比例的事情。作为开发者，我们看到的可能不只是一个“比例数字变化”，而是一整套计费系统、规则配置、结算链路和数据对账逻辑需要跟着调整。业务侧一句话，技术侧往往要动好几个服务。这篇文章想从工程角度聊一聊：网约车平台抽成比例下调，技术侧到底要改什么、怎么改，以及如何用一套可配置的规则引擎来支持这种频繁变化的计价需求。

如果你是刚接触交易系统、结算系统或者规则引擎的开发者，这篇文章能帮你理解计价系统的核心链路。如果你已经在做相关系统，文中的配置化方案、对账逻辑和灰度发布思路也可以作为参考。

1. 抽成比例下调，技术侧到底在改什么

1.1 业务上的“抽成比例下降”是什么

网约车平台连接乘客和司机。乘客支付一笔订单费用，平台从中抽取一定比例作为服务费，剩下的部分结算给司机，这就是“抽成”。抽成比例下降，意味着平台从每笔订单中留下的钱变少，司机拿到手的收入变多。

这个调整从业务角度看是定价策略变化，从系统角度看是一次典型的“计费规则变更”。规则变更不只是改一个数字那么简单，它涉及：

• 订单计价时按新比例计算抽成；
• 司机端收入明细展示要同步更新；
• 历史订单与当前订单要区分不同规则；
• 财务对账要能验证新规则是否正确执行；
• 如果规则配置错误，可能影响大量订单的资金结算。

1.2 技术视角：一次计费规则的变更

抽成比例下调，本质上是一个“规则版本”的更新。比如原来某档订单金额抽成 25%，现在调整为 20%。这个变化可以落在代码里，也可以落在配置中心或数据库规则表里。差别在于：

如果写死在代码里，每次调整都要发版，周期长、风险大、回滚麻烦。如果做成配置化规则，业务调整时可以只改配置或插入一条新规则，系统动态加载并生效，整个过程可控且可追溯。

网约车这类交易系统普遍采用后一种方式，也就是“规则引擎 + 配置化”的思路。下面我们会用一个简化版的抽成规则系统来演示完整设计。

1.3 为什么不能直接改代码写死比例

有的同学可能会想：抽成比例不就是commission = amount * 0.2吗？改一个数字不就行了？

现实中远比这个复杂。抽成规则通常不是统一比例，可能有以下维度：

• 按订单金额分段，不同区间不同比例；
• 按城市、车型、服务时段差异化；
• 按司机等级、口碑值、完单量浮动；
• 平台活动期间有临时抽成减免；
• 规则有生效时间和失效时间，历史订单按当时规则结算。

如果这些逻辑全部写死在业务代码里，每次调整都要改代码、走发布流程，而且容易漏改分支。更关键的是，资金相关逻辑必须可追溯：什么时候改的规则、谁改的、影响哪些订单，这些都需要记录。配置化 + 版本化是解决这类问题的基本手段。

2. 网约车计价与抽成的核心模型

2.1 订单金额组成

在一笔网约车订单中，乘客支付金额通常由几个部分构成：

• 起步价；
• 里程费；
• 时长费；
• 远途费、夜间费、天气溢价等附加费用；
• 平台优惠券抵扣。

这些费用汇总后得到订单的消费金额，也就是我们常说的“订单金额”。平台抽成就是从这个订单金额中按比例抽取。

2.2 抽成与结算的基本公式

抽成链路的核心公式很简单：

平台抽成金额 = 订单金额 × 抽成比例 司机收入 = 订单金额 - 平台抽成金额

假设订单金额为 100 元，抽成比例为 20%，那么：

平台抽成金额 = 100 × 0.20 = 20 元 司机收入 = 100 - 20 = 80 元

如果抽成比例从 25% 下调到 20%，同样的订单金额下，司机收入从 75 元变成 80 元，平台收入从 25 元变成 20 元。

2.3 计价系统涉及的模块划分

一个完整的计价与结算链路，通常包含以下几个模块：

在实际项目中，这些模块可能分散在不同微服务中，但核心计算逻辑是相通的。

3. 环境准备与工程结构

3.1 技术栈选型

本文的演示项目使用常见的技术栈，方便读者理解核心逻辑。你实际项目中不一定要用完全一样的框架，重点是掌握设计思路。

• JDK 17 或 JDK 8 均可；
• Spring Boot 2.7.x 或 3.x；
• MyBatis-Plus 或 Spring Data JPA；
• MySQL 8.x，用于存储规则和订单数据；
• Redis 可选，用于缓存规则配置。

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

3.2 项目结构

为了代码结构清晰，我们按下面的分包方式组织：

src/main/java/com/example/commission/ ├── CommissionApplication.java ├── controller/ │ └── RuleController.java ├── entity/ │ ├── RuleConfig.java │ ├── Order.java │ └── Settlement.java ├── mapper/ │ ├── RuleConfigMapper.java │ └── SettlementMapper.java ├── service/ │ ├── RuleEngine.java │ ├── RuleConfigService.java │ └── SettlementService.java └── vo/ └── SettlementResult.java

篇幅有限，这里不会贴出每个文件的完整代码，但核心文件都会给出可以运行的示例。

3.3 数据库表设计

抽成规则表用于存储不同版本、不同区间的抽成比例。

CREATE TABLE `t_rule_config` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `rule_version` int NOT NULL COMMENT '规则版本号', `min_amount` decimal(10,2) NOT NULL COMMENT '订单金额下限（含）', `max_amount` decimal(10,2) NOT NULL COMMENT '订单金额上限（不含）', `commission_rate` decimal(5,4) NOT NULL COMMENT '抽成比例，0.2000 表示 20%', `effective_time` datetime NOT NULL COMMENT '规则生效时间', `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态：1-有效，0-失效', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_version_effective` (`rule_version`, `effective_time`) ) ENGINE=InnoDB COMMENT='抽成规则配置表';

订单表和结算表是后续计算和验证的基础。

CREATE TABLE `t_order` ( `order_id` varchar(64) NOT NULL COMMENT '订单号', `order_amount` decimal(10,2) NOT NULL COMMENT '订单金额', `order_time` datetime NOT NULL COMMENT '下单时间', `city_code` varchar(16) DEFAULT NULL COMMENT '城市编码', PRIMARY KEY (`order_id`) ) ENGINE=InnoDB COMMENT='订单表'; CREATE TABLE `t_settlement` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `order_id` varchar(64) NOT NULL COMMENT '订单号', `order_amount` decimal(10,2) NOT NULL COMMENT '订单金额', `commission_amount` decimal(10,2) NOT NULL COMMENT '平台抽成金额', `driver_amount` decimal(10,2) NOT NULL COMMENT '司机收入', `rule_version` int NOT NULL COMMENT '使用的规则版本号', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_order_id` (`order_id`) ) ENGINE=InnoDB COMMENT='订单结算表';

这里把抽成比例设计成分段区间，是为了演示更贴近真实场景。假设平台调整抽成比例，通常是某一档或多档区间发生变化，而不是简单全局替换。

4. 抽成规则引擎核心实现

4.1 规则配置实体

先定义对应数据库表的实体类。

// 文件路径：src/main/java/com/example/commission/entity/RuleConfig.java package com.example.commission.entity; import java.math.BigDecimal; import java.time.LocalDateTime; public class RuleConfig { private Long id; /** * 规则版本号，同一版本下可以有多个分段区间 */ private Integer ruleVersion; /** * 订单金额下限（含） */ private BigDecimal minAmount; /** * 订单金额上限（不含） */ private BigDecimal maxAmount; /** * 抽成比例，0.2000 表示 20% */ private BigDecimal commissionRate; /** * 规则生效时间 */ private LocalDateTime effectiveTime; /** * 状态：1-有效，0-失效 */ private Integer status; // 省略 getter/setter }

这里最核心的是ruleVersion和effectiveTime两个字段。它们共同决定了“一笔订单应该使用哪一版规则”。

4.2 规则加载与缓存

规则引擎启动时会加载当前生效的规则集合到内存中，避免每次计算都查数据库。这里用@PostConstruct模拟初始化加载，实际项目中会结合缓存中间件，比如 Redis，并监听配置变更事件刷新缓存。

// 文件路径：src/main/java/com/example/commission/service/RuleEngine.java package com.example.commission.service; import com.example.commission.entity.RuleConfig; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import javax.annotation.PostConstruct; import java.math.BigDecimal; import java.time.LocalDateTime; import java.util.ArrayList; import java.util.List; import java.util.stream.Collectors; @Service public class RuleEngine { @Autowired private RuleConfigService ruleConfigService; /** * 当前生效的规则列表，按 minAmount 升序排列 */ private volatile List<RuleConfig> activeRules = new ArrayList<>(); @PostConstruct public void init() { refreshRules(); } /** * 刷新规则缓存，实际项目可改为监听配置变更或者定时刷新 */ public void refreshRules() { LocalDateTime now = LocalDateTime.now(); List<RuleConfig> allRules = ruleConfigService.getAllValidRules(); // 筛选出当前时间已生效的规则中版本号最大的集合 Integer maxVersion = allRules.stream() .map(RuleConfig::getRuleVersion) .max(Integer::compareTo) .orElse(0); List<RuleConfig> latestRules = allRules.stream() .filter(rule -> rule.getRuleVersion().equals(maxVersion)) .filter(rule -> !rule.getEffectiveTime().isAfter(now)) .sorted((a, b) -> a.getMinAmount().compareTo(b.getMinAmount())) .collect(Collectors.toList()); this.activeRules = latestRules; } /** * 根据订单金额计算平台抽成金额 * * @param orderAmount 订单金额 * @return 平台抽成金额 */ public BigDecimal calculateCommission(BigDecimal orderAmount) { if (orderAmount == null || orderAmount.compareTo(BigDecimal.ZERO) <= 0) { return BigDecimal.ZERO; } for (RuleConfig rule : activeRules) { if (rule.getStatus() != null && rule.getStatus() == 1 && orderAmount.compareTo(rule.getMinAmount()) >= 0 && orderAmount.compareTo(rule.getMaxAmount()) < 0) { // 按金额乘以比例，保留两位小数，四舍五入 return orderAmount.multiply(rule.getCommissionRate()) .setScale(2, BigDecimal.ROUND_HALF_UP); } } // 没有匹配到规则时，默认不抽成或返回 0，需要根据业务决定兜底策略 return BigDecimal.ZERO; } }

这里有几个容易踩坑的地方：

• BigDecimal的除法要指定精度和舍入模式，否则会抛ArithmeticException；
• 金额比较不能直接使用equals，因为0.20和0.200在BigDecimal中不是同一个值，应该使用compareTo；
• 规则集合是共享数据，多线程读写时需要保证可见性，这里使用了volatile修饰引用，避免读到半初始化的规则列表。

4.3 规则配置服务

RuleConfigService负责从数据库查询规则并对外提供刷新能力。

// 文件路径：src/main/java/com/example/commission/service/RuleConfigService.java package com.example.commission.service; import com.example.commission.entity.RuleConfig; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import java.util.List; @Service public class RuleConfigService { @Autowired private RuleConfigMapper ruleConfigMapper; /** * 查询所有状态为有效的规则配置 */ public List<RuleConfig> getAllValidRules() { return ruleConfigMapper.selectValidRules(); } }

对应的 Mapper 使用 MyBatis 注解方式实现：

// 文件路径：src/main/java/com/example/commission/mapper/RuleConfigMapper.java package com.example.commission.mapper; import com.example.commission.entity.RuleConfig; import org.apache.ibatis.annotations.Mapper; import org.apache.ibatis.annotations.Select; import java.util.List; @Mapper public interface RuleConfigMapper { @Select("SELECT id, rule_version, min_amount, max_amount, commission_rate, effective_time, status " + "FROM t_rule_config WHERE status = 1") List<RuleConfig> selectValidRules(); }

4.4 结算服务：计算抽成与司机收入

有了规则引擎之后，结算服务就变得很轻量。

// 文件路径：src/main/java/com/example/commission/service/SettlementService.java package com.example.commission.service; import com.example.commission.vo.SettlementResult; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import java.math.BigDecimal; @Service public class SettlementService { @Autowired private RuleEngine ruleEngine; /** * 结算一笔订单 * * @param orderId 订单号 * @param orderAmount 订单金额 * @return 结算结果 */ public SettlementResult settle(String orderId, BigDecimal orderAmount) { BigDecimal commission = ruleEngine.calculateCommission(orderAmount); BigDecimal driverIncome = orderAmount.subtract(commission); SettlementResult result = new SettlementResult(); result.setOrderId(orderId); result.setOrderAmount(orderAmount); result.setCommissionAmount(commission); result.setDriverAmount(driverIncome); // 实际项目中这里会异步保存 t_settlement 记录，并发送结算完成消息 return result; } }

结算结果对象：

// 文件路径：src/main/java/com/example/commission/vo/SettlementResult.java package com.example.commission.vo; import java.math.BigDecimal; public class SettlementResult { private String orderId; private BigDecimal orderAmount; private BigDecimal commissionAmount; private BigDecimal driverAmount; // 省略 getter/setter }

4.5 为什么规则引擎要这么设计

这里的设计核心是“把变化的规则从代码中抽离出来”。当业务人员提出新的抽成方案时，不需要修改SettlementService的代码，只要在规则配置表中插入新版本规则，然后调用refreshRules()刷新内存缓存即可。

这种设计有几点好处：

• 规则变更不需要发版，响应速度快；
• 规则有版本号，可以追溯历史计算逻辑；
• 同一时间只有一份生效规则，避免不同请求用了不同版本；
• 后续扩展城市、车型等维度时，只需增加匹配字段。

5. 模拟一次抽成比例下调的完整流程

5.1 准备初始规则

假设平台原来执行的抽成规则如下：

插入初始规则数据：

INSERT INTO `t_rule_config` (`rule_version`, `min_amount`, `max_amount`, `commission_rate`, `effective_time`, `status`) VALUES (1, 0.00, 50.00, 0.2500, '2024-01-01 00:00:00', 1), (1, 50.00, 200.00, 0.2200, '2024-01-01 00:00:00', 1), (1, 200.00, 99999999.00, 0.2000, '2024-01-01 00:00:00', 1);

5.2 业务侧调整抽成比例

现在业务方要求下调抽成比例，新规则变成：

注意：这条规则不是直接修改原来的记录，而是插入一个新版本rule_version = 2，并设置生效时间。这样可以保留历史规则用于追溯和对账。

INSERT INTO `t_rule_config` (`rule_version`, `min_amount`, `max_amount`, `commission_rate`, `effective_time`, `status`) VALUES (2, 0.00, 50.00, 0.2000, '2024-06-01 00:00:00', 1), (2, 50.00, 200.00, 0.1800, '2024-06-01 00:00:00', 1), (2, 200.00, 99999999.00, 0.1500, '2024-06-01 00:00:00', 1); -- 旧版本规则置为失效 UPDATE `t_rule_config` SET `status` = 0 WHERE `rule_version` = 1;

在正式环境中，UPDATE语句需要在事务中执行，并且建议先备份数据。这里演示的是规则调整的核心 SQL，实际系统往往通过管理后台完成这些操作。

5.3 编写测试用例验证新旧规则

写一个简单的测试类，验证规则刷新前后，同样金额的订单计算出的抽成金额不同。

// 文件路径：src/test/java/com/example/commission/SettlementServiceTest.java package com.example.commission; import com.example.commission.service.RuleEngine; import com.example.commission.service.RuleConfigService; import com.example.commission.service.SettlementService; import com.example.commission.vo.SettlementResult; import org.junit.jupiter.api.Test; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.test.context.SpringBootTest; import java.math.BigDecimal; @SpringBootTest public class SettlementServiceTest { @Autowired private SettlementService settlementService; @Autowired private RuleEngine ruleEngine; @Autowired private RuleConfigService ruleConfigService; @Test public void testCommissionRuleChange() { // 模拟旧规则下 100 元订单的结算结果 // 旧规则：50~200 元区间抽成 22% // 注意：这里直接复用 RuleEngine 会读取当前生效规则， // 所以先刷新规则再计算，对比结果由差异体现 // 刷新规则（如果数据库中只有新规则，这里会加载新规则） ruleEngine.refreshRules(); BigDecimal orderAmount = new BigDecimal("100.00"); SettlementResult result = settlementService.settle("ORDER20240601001", orderAmount); System.out.println("订单金额：" + result.getOrderAmount()); System.out.println("平台抽成：" + result.getCommissionAmount()); System.out.println("司机收入：" + result.getDriverAmount()); // 如果当前生效的是新规则，抽成为 18 元，司机收入 82 元 // 如果当前生效的是旧规则，抽成为 22 元，司机收入 78 元 // 测试断言需要根据数据库实际规则版本调整 } }

5.4 运行结果说明

运行测试方法后，控制台会输出类似下面的内容：

订单金额：100.00 平台抽成：18.00 司机收入：82.00

这个结果说明当前生效的是版本 2 的新规则。如果输出的是抽成 22 元，则说明规则刷新没有成功，需要检查：

• t_rule_config中新版本规则的effective_time是否早于当前时间；
• 旧版本规则是否已经被置为失效；
• RuleEngine.refreshRules()是否被调用。

6. 抽成调整后的对账方案

6.1 为什么必须对账

涉及资金计算的系统，任何规则调整都可能引入风险。抽成比例下调后，平台需要验证：

• 每一笔订单都按正确的比例抽成；
• 司机收入计算正确；
• 平台抽成金额与财务入账金额一致；
• 不存在漏结算、重复结算的订单。

对账就是通过独立计算和交叉验证，发现结算链路中的问题。

6.2 基于订单与结算表的对账 SQL

一份基础的对账 SQL 可以这样设计：

-- 找出订单金额与结算记录不一致的数据 SELECT o.order_id, o.order_amount, s.commission_amount AS actual_commission, s.driver_amount AS actual_driver_amount, ROUND(o.order_amount * 0.18, 2) AS expect_commission, ROUND(o.order_amount - o.order_amount * 0.18, 2) AS expect_driver_amount, CASE WHEN s.commission_amount = ROUND(o.order_amount * 0.18, 2) AND s.driver_amount = ROUND(o.order_amount - o.order_amount * 0.18, 2) THEN 'OK' ELSE 'DIFF' END AS check_result FROM t_order o LEFT JOIN t_settlement s ON o.order_id = s.order_id WHERE o.order_time >= '2024-06-01 00:00:00' AND o.order_time < '2024-06-02 00:00:00';

这段 SQL 用当前的新抽成比例重新计算预期抽成金额，再和实际结算记录做比较。如果check_result出现DIFF，就需要人工介入排查。

注意：上面的 SQL 中把比例写死为0.18只是为了演示对账思路。在真实系统中，对账程序应该读取t_rule_config中当前生效的规则，而不是在 SQL 中硬编码数值。

6.3 对账异常处理

对账发现差异后，一般按照下面的流程处理：

1. 锁定问题订单，标记为“对账异常”状态，不进入打款流程；
2. 根据订单时间和城市等信息，确定当时应该使用的规则版本；
3. 重新计算正确的抽成金额和司机收入；
4. 更新结算记录，并记录操作日志；
5. 如果涉及资金已经打款，需要走人工退款或补扣流程。

这里需要特别强调：涉及资金数据的修正操作，必须在测试环境充分验证，并且在生产环境保留完整操作审计。动资金数据不是小事，要严格遵循最小权限原则。

7. 灰度发布与监控

7.1 规则变更为什么需要灰度

抽成比例调整会影响所有订单的结算，如果新规则有问题，影响面会非常大。所以不能一上来就对全量订单生效，而是要通过灰度发布逐步验证。

常见做法是按城市、按司机比例或者按订单比例灰度。比如先让某一个城市的订单使用新规则，观察一段时间，确认数据正常后再扩大到更多城市。

7.2 发布策略

灰度发布的核心是让一小部分流量先使用新规则，其余流量继续使用旧规则。这个能力需要在规则引擎中增加“灰度开关”支持。

可以给RuleConfig增加一个gray_type字段，比如：

• 0：全量使用；
• 1：按城市白名单；
• 2：按订单号哈希取模；
• 3：按司机 ID 取模。

规则引擎在匹配规则时，先判断当前订单是否命中灰度策略，如果命中就使用新版本规则，否则走旧版本。灰度发布过程中要时刻关注监控指标，确认没有异常后再逐步放量。

7.3 监控指标

抽成比例调整后，至少要看以下指标：

监控不是只做一次，而是在灰度期间持续观察，至少覆盖一个完整的业务周期，比如一个周末加一个工作日，因为不同时间段订单金额分布差异很大。

8. 常见问题与排查思路

下面整理一些抽成规则系统开发和上线过程中常见的问题。

再多说一个开发中容易被忽略的问题。规则配置表中，同一版本的多条区间数据必须保证区间连续且不重叠。如果出现“50 到 100”和“80 到 200”同时存在的情况，规则引擎匹配时可能走错分支。建议在配置管理后台做规则区间校验，新增或修改规则时自动检查。

9. 最佳实践与工程建议

9.1 规则版本化，不要直接覆盖历史数据

抽成比例调整，永远不要直接修改历史规则。正确做法是新增一个规则版本，并设置好生效时间。好处是：

• 历史订单可以按当时的规则版本追溯计算过程；
• 财务审计时可以还原任意时间点的抽成比例；
• 出问题时可以快速回滚到上一个版本。

9.2 金额计算统一使用 BigDecimal

涉及资金的计算，统一使用BigDecimal，禁止使用double或float。同时要明确规定精度和舍入模式，一般金额保留两位小数，使用ROUND_HALF_UP。

// 推荐写法 BigDecimal commission = amount .multiply(rate) .setScale(2, BigDecimal.ROUND_HALF_UP);

9.3 结算必须幂等

结算接口可能因为网络重试、消息重复消费等原因被调用多次。没有幂等保护的话，会产生重复结算记录。常见做法是在t_settlement表上给order_id建唯一约束，插入时使用INSERT IGNORE或者先查后插。

9.4 对账要常态化

抽成比例调整之后的一次性对账并不够。实际项目中应该建立每日对账任务，自动扫描前一天所有订单的结算数据，发现差异立即告警。对账是资金系统的最后一道防线，不能省略。

9.5 规则变更要走审批和审计

抽成规则直接影响平台收入和司机收入，属于敏感配置。规则调整应该通过管理后台操作，支持审批流，记录操作人和操作时间。生产环境的规则变更遵循最小权限原则，不允许开发人员手动改生产库表。

9.6 为规则引擎预留扩展维度

现在的规则引擎只按订单金额匹配，但真实场景下抽成规则可能需要按城市、车型、时段等维度区分。设计时要预留扩展字段，比如city_code、vehicle_type、time_slot等，避免后续需求一来就重构规则引擎。

10. 总结与下一步学习方向

这篇文章从网约车平台抽成比例下调这个业务事件出发，讲解了抽成规则系统的设计思路。我们重点梳理了以下内容：

• 抽成比例调整在业务和技术两侧实际意味着什么；
• 网约车订单计价、抽成和结算的核心公式；
• 如何用规则配置表 + 规则引擎实现抽成规则的配置化；
• 如何通过规则版本管理支撑比例调整和追溯；
• 抽成调整后如何通过对账 SQL 验证数据；
• 灰度发布、监控指标和常见问题排查方法。

如果接下来想继续深入，可以从这几个方向入手：

• 学习规则引擎的成熟框架，比如 Drools，了解复杂规则如何编排；
• 研究配置中心的原理，比如 Apollo、Nacos，了解规则配置如何动态下发到各个服务；
• 深入学习对账系统的设计，包括实时对账和离线对账的差异；
• 研究分布式事务在结算链路中的应用，保证订单、结算、财务数据的一致性。

抽成比例下调对乘客和司机来说是一个信息，但对开发者来说，它是一次完整的规则变更和资金链路验证。希望这篇文章能帮你建立起对计费结算系统的整体认知，也欢迎在实际项目中动手实践。如果你的系统里也有类似的价格规则、抽成规则或者分成规则，可以试试改成配置化的思路，后面再做调整时会轻松很多。