访问控制 RBAC / ABAC 总览待审核
实例 · 会员价 / 优惠券

会员价 + 优惠券:当 policy 不输出准/拒,而是算一个价

收银台那行「应付 ¥XX」,本质和 01–05 页的判定一模一样:把一套促销规则 (rule) 应用到购物车 (context) 上。 唯一的推广是 —— 这次决策不再是 permit / deny,而是一个值 (最终价) + 用上了哪些优惠。 这就是规则引擎 (rule engine),policy 的近亲。四个轴照样在:

who
会员等级
普通 / 银卡 / 金卡 / PLUS → 会员价
what
购物车商品
品类 / 单价 / 数量 → 满减门槛、限品类券
action
结算
触发定价
when
券有效期 / 活动时段
本页从略,同 03-when-where 的情境
一条优惠券 = 一条 rule。05-decide 的规则同构,只是 effect 从「permit/deny」变成「改价」:
{ 条件 when(cart): 满200 / 限图书 / 限新人,   效果 effect: −¥30 / ×0.95 / 包邮,   互斥组,   优先级 }
「会员价和券能不能叠?多张券怎么算?谁先谁后?」就是 05-decide组合算法的促销版 —— 而且它顺序敏感

收银台促销引擎

🛒 购物车 (what) —— 调数量看满减门槛

👤 会员等级 (who) —— 决定会员价

🎟️ 持有的优惠券 (选中 = 尝试使用)

🔧 叠加策略 (组合算法) —— 同一车,不同策略不同价

优惠应用明细 (绿 = 已用并省了多少;灰 = 跳过及原因)

同一辆车,三种叠加策略三个价

叠加策略不是细节,它直接决定你付多少 —— 也决定商家让不让你这么省。用当前购物车同时跑三种:

顺序敏感直接影响金额。对比「先折扣后满减」「先满减后折扣」:满减是固定减额, 折扣是乘法 —— 谁先谁后,最终价不同 (本页满减门槛按原价判,所以差异全来自「−额」落在「×折扣」前还是后)。 真实电商必须把应用顺序写死进文档,否则同一车在两次结算给出不同价,就是事故。这正是 05-decidefirst-applicable「顺序即优先级」的同一机制。 「自动选最省」= 在 policy 空间里做优化。「券互斥」策略下,引擎会把每张可用券各算一遍, 替你挑实付最低的那一张 (其余标「互斥跳过」)。这比单纯判 permit/deny 更进一步: 决策从「命中哪条」升级成「哪种组合最优」。也正因为叠加往往比互斥更省,商家才用互斥来控制让利成本。

促销概念 → policy 概念

促销里的说法policy 里的概念 (第 01–05 页)
满200 / 限图书 / 限新人规则条件 when(req) (eligibility / applicability)
−¥30 / ×0.95 / 包邮规则效果 effect (这里不是 permit/deny,是改价)
券与券 / 券与会员价 互斥combining algorithm:互斥 ≈ 选一个 (这里选最优)
先满减还是先打折应用顺序 ≈ first-applicable「顺序即优先级」
折扣封顶 / 最低实付 ¥0约束 / obligation (上限下限)
没有任何券命中默认决策 = 原价 (default,no-op 的 permit)
最终「应付」decision 的返回值 (一个数,不是布尔)

相关链接