问卷系统里的逻辑跳转，本质是把"受访者的作答状态"映射到"下一步该显示或跳转到哪里"的规则集合。当分支从"单题单跳"升级为多答案组合判断、分数区间路由、题目间显隐联动，甚至用表达式控制时，硬编码 if-else 很快会失控。DSL（领域特定语言）引擎的价值，就在于把这些规则从程序代码里抽离出来，变成一套可声明、可解析、可执行的描述。
规则如何被描述与解析
DSL 的第一步是设计一套贴合问卷语义的表达方式，让"选了 A 跳第 5 题""分数落在某区间走另一条路径"这类意图能被结构化地写出来。引擎拿到这段描述后，通常先做词法与语法解析，把文本转成抽象语法树（AST）这样的中间结构。解析阶段的职责是校验表达式是否合法、引用的题目是否存在、条件组合是否自洽，从而把错误拦在运行之前，而不是等用户答题时才暴露。
规则如何被求值与触发
解析完成后，引擎需要一个求值环境，把受访者的实时作答作为上下文变量喂进去。每当作答状态变化，引擎遍历相关规则，对条件表达式求值，再根据结果决定题目的显示、隐藏或跳转目标。这里的关键在于依赖关系管理：题目之间互相关联显隐时，一处改动可能牵动多条规则，引擎要能确定重新计算的范围，避免遗漏或重复触发。表达式支持的运算越丰富，组合判断、区间匹配、跨题引用越灵活，背后的求值逻辑和边界处理也越复杂。
正因如此，DSL 引擎属于逻辑跳转里的高阶做法。它把复杂度从业务代码转移到了引擎设计与规则校验上，换来的是规则可维护、分支可扩展、测试可覆盖。对需要复杂条件分支的调研或测评场景，这种投入通常是值得的；而只需要基础跳转的常规问卷，未必需要动用完整的引擎能力。判断要不要上 DSL，核心还是看逻辑分支的真实复杂度，以及后续规则是否会频繁调整。
