第18章：表驱动方法

为什么需要这一机制

想象一张值班室里的纸表：每个输入旁边写着唯一结果，换班的人也能检查它。若这些规则散落在十几个 if 里，新增一条规则就可能漏改一处、顺序冲突一处，最后只能靠几个样例猜测程序是否完整。

第18章的解决方式是把稳定的业务决定移到数据中，再用一条明确的查找路径取回结果。这样做不是“把代码换成数组”这么简单；表必须说明允许哪些键、每一行代表什么、越界如何处理，以及数据改动后怎样证明旧输入仍得到同一结果。

核心合同：规则是数据，访问是承诺

把表看成一组带名字的行。每一行包含可比较的键或阈值，以及一个结果；查询代码只负责按照合同选择行，不再把业务规则复制进分支。这里的 表驱动方法 仍然需要程序，只是把“哪些输入得到什么结果”变成可以单独审查的数据。

查询前要先构造 查询键。键的单位、版本和缺省策略必须和表一致，否则 table[key] 的成功返回并不能证明命中了正确规则。

对于离散键，合同可以写成：

这个式子在说：键域内的每个键对应一个明确结果，键域外的输入必须走可见的拒绝或报告路径。

对于连续区间，合同可以写成：

这个式子在说：阶梯查找选择“不超过输入的最大阈值”，因此阈值顺序、边界含义和超范围处理都属于数据合同，而不是实现细节。

目录节点到可验证证据

下面逐项对齐第18章的官方目录。每个节点都同时给出规则解释、边界探针和练习中的复核位置；标题只是入口，能在实验中指出状态变化才算覆盖。

第18章 表驱动方法

总原则是先分离规则数据和访问代码，再验证两者之间的接口。稳定规则适合放入表，频繁变化的流程控制仍应留在代码；表越灵活，键域、版本和默认策略越要显式。实验中先选择完整表，再注入缺键，观察拒绝是否发生在查询前。

18.1 表驱动方法使用总则

使用表驱动方法前先问两个问题：规则是否稳定到值得数据化，数据是否能用一条清晰的访问合同表达。若每一行都要写一段特殊代码，表只是把复杂度藏起来；若规则来自可审查的配置，表可以让评审者直接看到覆盖范围。把表加载、校验和查询分成三步，故障才不会被结果掩盖。

使用表驱动方法的两个问题

第一个问题是“我在替代哪一组重复决定”：例如月份到天数、保费到费率、消息类型到格式。第二个问题是“查找的键是否稳定”：同一个业务输入必须构造同一个键，不能一次使用月份编号、下一次使用数组位置。先回答这两个问题，再决定直接、索引还是阶梯访问。

18.2 直接访问表

直接访问表适合月份、命令名或消息类型这类离散键。数组位置不应自动等同于业务键：如果月份从 1 开始，代码要么保留一个明确的哨兵位置，要么先把月份转换为合法索引。缺键不能返回二月的天数，也不能把数组越界当作业务规则。

示例：一个月中的天数（Days-in-Month）

把月份作为键、天数作为值时，month = 2 应命中 28；month = 13 则应在查表前被拒绝。闰年不是“再加一个神秘条件”，而是需要写进键的定义，或者使用 (year, month) 的复合键。复核证据应记录输入月份、闰年规则、命中行和未知月份的处理。

示例：保险费率

保险费率通常不是一个简单的离散键，而是由年龄、风险等级或保额共同决定。先把输入归一化为稳定键，例如 (riskTier, coverageBand)，再让直接访问表返回费率。任何单位转换都要在构造查询键时完成，并在表版本中留下记录；否则同一个“500”可能被误读成月保费、年保费或金额分档。

例子：灵活的消息格式（Flexible-Message-Format）

消息格式可以把字段顺序、可选字段和版本放入结构化表，而不是在字符串拼接中散落条件。格式表的每一行要说明输入消息类型、输出字段和缺失字段的处置。灵活不等于无限兜底：遇到未知版本应拒绝并记录，而不是悄悄使用最旧格式。

构造查询键值

键构造是表查询最容易被低估的边界。先确定输入的类型、单位、大小写和版本，再做规范化；规范化之后要能解释为什么两个业务输入会得到同一个键。复核时固定表版本，只改变一个键字段，检查首个变化发生在键构造还是查找结果。

18.3 索引表访问（Indexed Access Tables）

索引表把“查找”拆成键到位置的转换和位置到结果的读取。它适合位置本身有意义、范围固定的场景，例如星期几或小型状态编号。索引函数必须检查下界和上界；位置合法只说明内存可访问，不说明业务键有效。

18.4 阶梯访问表

阶梯访问表适合保费、数量和性能等级这类连续输入。表的阈值必须单调递增、不能重复，并且要说明输入小于最小阈值和大于最大阈值时的结论。把 500 和 1000 的顺序调换，会改变“最大的不超过输入”这一选择，因此排序是规则的一部分。

18.5 表查询的其他示例

其他查询可以包括错误码到修复动作、地区到时区、产品版本到能力集合。共同的检查方式是：先写键的来源与单位，再选择访问合同，最后列出未知键、过期版本和缺少行时的处理。表越大，越需要把加载时校验与运行时查询分开，以便在服务启动时尽早发现配置错误。

关键点

表驱动方法的关键不是“表比 if 短”，而是让规则具有独立的数据边界和可复核的访问语义。读者应该能回答：这一输入的键是什么，命中了哪一行，为什么不是相邻行，若没有匹配行程序会怎样，以及重置后同一输入是否仍得到同一结果。若这些问题答不出来，就还没有完成表驱动化。

最小可重放实现

table = load_versioned_rules()
validate_keys_order_and_defaults(table)
key = build_query_key(input)
result = lookup(table, key)
record(input, table.version, key, result)
assert reset_and_lookup(input) == result

这段草图把加载校验、键构造和查询分开，方便在同一输入上替换一种访问策略。真实实现还应记录表版本、单位、边界样本、拒绝理由和复位后的结果；否则一次成功查询不能证明规则完整。

专属因果实验

先预测：把键从 2 改为 13，或把阈值 500 与 1000 调换，哪一个节点会最先变化？动手试三个场景，再用单步或播放检查变化是发生在键构造、配置校验、访问选择还是结果验证。最后点击每个实验的“重置实验”，确认输入、故障开关、时间线和结果文字回到基线。

故障诊断与误区

当结果不对时，按以下顺序缩小范围：先检查输入单位和版本，再检查查询键是否稳定，然后检查表的缺键、重复键和顺序，最后才检查访问代码。若故障在表加载时就能拒绝，就不要把它延后到业务请求中；若故障只在边界出现，就保留边界输入和首个偏离，而不是只截图最终结果。

本页小结

• 把稳定规则移入数据，但把键域、版本和缺省策略写成合同。
• 直接访问适合离散键，索引访问适合稳定位置，阶梯访问适合连续阈值。
• 查询键负责单位与版本对齐，表校验负责拒绝缺键、重复键和乱序。
• 正常值、恰好边界、故障输入和重置重放共同构成证据。