配置驱动 / 脚本驱动

Category

glossary 词条。节点定位：配置驱动承接受值变化、脚本驱动承接逻辑变化——同答「哪些变化不走完整发版」，不能互相替代。

Definition

这两个词经常一起出现，因为它们在回答同一个问题：哪些变化不应该走完整的代码发布链路。区别在于变化的复杂度和风险形态：配置驱动承接受值层面的变化，脚本驱动承接逻辑层面的变化。

Problem

把逻辑塞进配置（表里长出 if-else）、把数值放进脚本（改数要审代码），两边都错位：复杂度与风险形态不同，载体错配后校验、权限、回滚全部失灵。灰色地带要显式归类而不是随手放。

配置驱动适合承载什么

配置驱动的价值，是把变化从代码发布链路中拆出来，让规则参数、内容组合和部分静态结构更快调整。数值曲线、掉落表、商店货架、活动开关这类结构稳定、取值多变的东西，通常适合放进配置。它的收益不只是快，还有变更可审计：每次变化是一次配置提交，而不是一次代码发布。

脚本驱动适合承载什么

脚本驱动适合逻辑本身在变的情况：条件组合、流程编排、表达式判断。这些用表格硬描述会迅速失控，表里长出一门谁都不敢动的语言。脚本比配置灵活，但也更容易破坏发布纪律，所以它通常需要额外的版本管理、审核流程和回滚机制，而不能借用“配置不用测试”的惯性。

两者不能互相替代

把逻辑塞进配置，表格会退化成一种难懂的编程语言；把参数写死在脚本，每次调数值都要走完整发布。判断某类变化放哪边，通常看两个问题：变化的是取值还是结构，出错后的止损窗口要求多短。取值变化且要快，配置；结构变化且允许审核，脚本。

一条实用的分类检验

拿不准一个变化放哪边时，常见做法是问两个问题：这个变化要交给非程序角色自助完成吗，出错后要在几分钟内回滚吗。两个都答是，配置；第一个答否，多半是脚本；第二个也答否，说明它连配置都不该是，应该是走完整流程的代码变更。

检验会漏掉一些中间形态，拿不准时先按风险高的那边治理，通常比事后补救便宜。

两类载体各自的失效方式

• 配置的失效方式：字段越加越多，语义靠注释，改一处的影响面没人说得清，最后没人敢动。
• 脚本的失效方式：绕过测试直接上线，崩溃后难以定位，宿主和脚本版本互相追着修。
• 共同的失效方式：没有灰度和回滚，错误直接作用到全量玩家。

失效方式提醒我们，两者的治理重点不同：配置重在结构和校验，脚本重在版本和审核，混在一起治理通常两头都做不好。

配置驱动不等于交给策划

更准确的理解是，配置驱动把规则变化纳入正式工程治理：表格要有结构和校验，变更要有灰度和回滚，而不是“改个表不用测试”。配置链路一旦绕过质量流程，它积累的速度优势会被一次配置事故全部吐出来，还会赔上团队对配置系统的信任。

灰色地带怎么处理

条件表达式、规则脚本、可编程的活动模板，介于两者之间。常见做法不是争论它们算配置还是算脚本，而是按风险分级：只读参数低风险，可执行逻辑高风险，风险越高越要补审核、灰度和回滚。分级标准落到工程上，通常是看这段变化最坏能直接影响多少玩家资产。

和热更新是什么关系

配置和脚本之所以值得单独讨论，是因为它们常常通过热更通道生效，速度优势也来自这里。热更解决怎么生效，配置驱动和脚本驱动解决什么变化值得这样生效，两件事不能互相定义。通道越快，越说明入口治理要越严。

引入脚本驱动前先回答什么

• 脚本由谁写、谁审核、走什么测试。
• 脚本崩溃怎么定位，日志和堆栈能不能还原到脚本版本。
• 宿主升级时，旧脚本怎么兼容。
• 出问题时回滚到哪个版本，多快生效。

这些问题答不清楚就引入脚本层，通常会拖垮的是整体发布纪律，而不是只影响脚本这一块。

表格之外的配置形态

除了表格，配置还有常见变体：活动编排的结构化描述、规则引擎的条件树、平台提供的远程参数。形态不同，判断标准相同：结构是否稳定、取值是否多变、出错能不能快速回滚。形态花哨不等于治理到位，不少项目的远程参数没有校验和版本，出起事故比表格更难查。

常见误区

• 把“什么都能配”当灵活性，配置表越堆越大，最后没人敢动。
• 脚本热更绕过测试和审核，成为绕开发布纪律的通道。
• 配置没有校验和灰度，错误直接打到全量玩家。
• 认为配置驱动等于不用发版，忽略配置和代码版本之间的兼容窗口。

Used By

变更载体选型；配置管线的边界评审；灰更体系的能力划分。

Related

关系链：配置承载 → 脚本承载 → 互不替代 → 分类检验 → 失效方式 → 热更关系。上游：glossary/04（谁改权威状态）。下游：production/config 子树、client/04（脚本与 ECS）。

Reference

本页为工程经验归纳。