配置驱动与脚本驱动

Category

system / 脚本与热更子树。节点定位：配置驱动与脚本驱动的分界——配置越做越像脚本、脚本变成万能补丁是两条常见越界，边界判断要前置，配置系统本身也要工程化。

Definition

项目需要更灵活时，很多团队会同时想到两种手段：把更多行为写进配置，或者把更多逻辑放进脚本。两者都能提升迭代速度，但它们解决的不是同一类问题。配置更擅长表达规则参数和静态组合，脚本更擅长表达流程、分支和运行时行为。把两者混为一谈，通常会得到一种既难维护又难校验的中间态。

所以这里真正要回答的，不是“配置和脚本谁更先进”，而是“什么变化适合被数据化，什么变化必须保留成可执行逻辑”。

Problem

配置越做越像脚本，是因为业务复杂度从脚本层漏了下来；脚本变成「万能配置补丁」，是因为没有建立准入判断。两条越界都会让改动成本失控——分界必须是显式判断，不能靠习惯。

配置驱动真正值钱的地方

配置驱动最有价值的，是把变化从代码发布链路中拆出来，让规则参数、内容组合和部分静态结构可以更快调整。它特别适合：

• 数值和规则参数
• 掉落、任务、活动条件
• UI 布局或页面组合关系
• 文本、多语言、资源映射
• 有限状态下的静态分支

配置的优势不只是“改得快”，更是它更容易被审核、校验、比对和回滚。

脚本驱动更适合解决什么

脚本更适合那些已经超出“参数表述”范围的问题，例如：

• 复杂流程编排
• 动态条件分支
• 需要运行时状态判断的行为
• 高频变化但又不值得全量发版的逻辑

换句话说，脚本适合表达“怎么做”，配置更适合表达“有哪些输入和约束”。

为什么很多项目会把配置越做越像脚本

这是非常常见的失控路径。项目初期配置只承载参数，后面为了避免改代码，团队不断往配置里加：

• 条件表达式
• 嵌套规则
• 事件回调名
• 执行顺序描述
• 小型 DSL

到最后，配置表面上还是数据，实际上已经变成了缺乏调试器和类型系统的脚本语言。这类系统前期看着灵活，后期最容易制造线上事故。

反过来，脚本也不该变成“万能配置补丁”

如果任何数据问题、表现问题、流程问题最后都靠脚本临时修，常见结果是：

• 脚本层越来越像业务垃圾回收站
• 配置和脚本的职责越来越模糊
• 同一个规则一半在配置一半在脚本
• 排障时很难判断究竟是哪一层出错

所以真正重要的不是“谁能做”，而是“谁应该默认做”。

一个更稳妥的边界判断

可以先用下面几个问题来判断：

• 这次变化是参数变化，还是行为变化
• 能不能通过静态校验提前发现错误
• 是否需要复杂的运行时上下文
• 是否需要调试、断点和执行追踪

如果答案更偏参数和静态组合，就更适合配置；如果答案更偏流程、条件和运行时判断，就更适合脚本。

为什么配置系统本身也必须被工程化

很多团队把配置系统想得过于轻量，觉得只要能编辑表格和导出文件就够了。真实项目里，配置系统往往是事故高发入口，因为它连接着策划、客户端、服务端和发布链路。一个成熟的配置系统通常需要：

• 类型校验
• 引用校验
• 差异审查
• 灰度发布
• 历史追踪和回滚

也就是说，配置驱动不是“把研发工作交给表格”，而是把规则变化纳入正式工程治理。

常见误区

最常见的错误，是把配置系统无限扩展成一门隐形脚本语言。第二类错误，是把所有高变逻辑都推给脚本层，配置退化成松散的数据仓库。第三类错误，是只看编辑体验，不补类型校验、审计和回滚能力，结果配置和脚本都变成高风险入口。

Used By

配置与脚本的准入评审；配置系统工程化建设。

Related

关系链：配置价值 → 脚本适合面 → 配置越界 → 脚本越界 → 边界判断 → 配置工程化 → 常见误区。上游：scripting/02（集成面）、production/05（配置管线）。下游：scripting/04（热更的对象与节奏）。

Reference

本页为工程经验归纳。