Function字典表通过handler_ref字段动态路由至计费策略，启动时扫描@BillingStrategy注解构建内存函数映射，运行时按sort_order和enabled查库获取激活策略列表，再从内存Map中顺序执行对应Function，实现策略可插拔、零代码变更。
在购物车多模式结算场景中，用 Function 字典表实现动态路由到不同计费策略，核心是把“结算方式 → 计费逻辑”映射关系变成可配置、可扩展、不改代码就能新增策略的结构。关键不在字典表本身，而在如何让字典表真正驱动运行时行为。
Function 字典表不是存 SQL，而是存可执行函数引用
字典表（如 billing_strategy）字段建议至少包含：strategy_code（如 'vip_discount', 'group_buy', 'flash_sale'）、strategy_name、enabled、sort_order，以及最关键的 handler_ref（字符串，例如 'VipDiscountCalculator.calculate' 或 'GroupBuyCalculator.apply'）。
注意：handler_ref 不是硬编码调用，而是运行时解析并安全调用。推荐做法：
- 启动时扫描所有标记了 @BillingStrategy 注解的类/方法，构建内存级 Map<String, Function<Cart, BillResult>>
- 字典表只作策略元数据管理（启用状态、优先级、描述），不直接存函数体或反射路径
- 若必须存字符串路径，用白名单校验 + ClassLoader.loadClass + MethodHandle 更安全，避免任意类加载
结算入口统一，靠策略上下文决定走哪条链
用户提交结算时，请求里带 selected_strategy_codes（数组，如 ['vip_discount', 'flash_sale']）或由系统根据商品/用户标签自动匹配。此时不手动 if-else，而是：
- 查字典表，按 sort_order 和 enabled 过滤出当前可用且激活的策略列表
- 按顺序从内存 Function Map 中取出对应函数，组成执行链（支持串行、条件跳过、短路等）
- 每个函数接收 Cart 对象，返回 BillResult（含金额变更、明细说明、是否影响后续策略），供下一个策略消费
示例伪代码：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
cart = loadCart(cartId);
List<String> activeCodes = strategyDao.findActiveCodesByCart(cart);
List<Function<Cart, BillResult>> calculators = activeCodes.stream()
.map(code -> functionRegistry.get(code))
.filter(Objects::nonNull)
.collect(toList());
BillResult finalResult = calculators.stream()
.reduce(BillResult.empty(),
(result, calc) -> calc.apply(cart.withCurrentResult(result)),
(a, b) -> b);
策略可插拔，新增只需三步，不碰主流程
加一种新计费方式（比如“老带新返现”）：
- 写一个类 ReferralCashbackCalculator，实现 Function<Cart, BillResult> 接口
- 加一条字典记录：strategy_code='referral_cashback', handler_ref='ReferralCashbackCalculator.apply', enabled=1
- 重启或触发策略热加载（通过监听字典表变更或 Admin 页面刷新缓存）
无需修改任何 if/switch、不改结算主方法、不改订单域模型 —— 真正做到策略与编排分离。
防坑要点：隔离、幂等、可观测
多个策略共存易引发冲突，需约束设计边界：
- 输入隔离：每个策略只读取 cart 的特定字段（如 user.vipLevel、items[].tag），不直接改原始对象，靠 BillResult 传递副作用
- 幂等保障：函数内部不做 DB 写操作；所有持久化由结算主流程统一提交，策略只负责计算
- 可观测性：记录每一步策略执行耗时、输入输出、是否跳过，方便排查“为什么没打折”这类问题
不复杂但容易忽略。
