1. 课程导入

在风控系统里，规则是业务意志最直接的表达。早期团队常把规则写成硬编码的 if/else，上线一条“同设备注册超过5个账号即拦截”要改代码、走发布、回归测试，等真正生效时黑产早已换招。风控规则DSL（Domain-Specific Language，领域特定语言）正是为解决这一矛盾而生：它是一种专门面向风控决策场景设计的、受约束的小语言，让业务人员能用接近自然语言的表达式描述风险判断，由引擎负责解析、编译与执行。

需要先厘清一个常见误解：DSL不等于“把JSON配置读进来”。JSON只是数据载体，而DSL包含语法、语义、类型系统、作用域与执行模型。一个合格的风控规则DSL至少要回答四个问题：能表达什么（事件属性、名单、聚合统计、时间窗口）、如何组合（与或非、优先级、短路）、如何求值（变量绑定、函数调用、缺失值处理）、如何治理（版本、灰度、回滚、审计）。

核心原理：DSL的三层结构与执行链路

从工程视角看，风控规则DSL通常分为三层。第一层是词法与语法层，把规则文本切分为并构建抽象语法树（AST）；第二层是语义与类型层，校验字段是否存在、类型是否匹配、函数参数是否合法；第三层是执行与优化层，将AST编译为可复用的执行计划，在每次请求时绑定事件上下文并求值。

规则文本:
  user.age < 18 AND device.riskScore >= 80
  AND count(register, ip, 1h) > 5

AST 片段:
  BinaryExpr(AND)
   ├── BinaryExpr(<)  → Field(user.age), Literal(18)
   ├── BinaryExpr(>=) → Field(device.riskScore), Literal(80)
   └── FuncCall(count) → args[event=register, key=ip, window=1h]
        └── BinaryExpr(>) → Literal(5)

执行链路可以概括为：解析 → 校验 → 编译 → 缓存 → 求值 → 决策。其中“编译”和“缓存”是性能关键：规则不应每次请求都重新解析，而应在发布时编译为字节码或闭包，运行时只做上下文绑定与计算。下图展示了这一链路与各阶段的核心产物。

价值：为什么值得为规则单独造一门语言

• 业务可读：规则以接近自然语言的形式呈现，风控运营可独立审阅与调整，减少“翻译损耗”。
• 变更高效：规则发布与代码发布解耦，支持热更新、灰度与秒级回滚。
• 安全可控：DSL是受限语言，没有循环、IO与任意函数调用，天然规避注入与死循环风险。
• 可观测：每条规则可独立统计命中率、耗时与误杀率，为策略迭代提供数据基础。
• 可复用：字段、函数、名单等能力沉淀为统一语义层，避免各系统重复实现。

典型应用场景

整体学习路线图

本课程共30章，按“认知—设计—实现—治理—实战”五段推进。第一阶段建立DSL的整体认知与语法设计能力；第二阶段深入解析器、AST与类型系统；第三阶段实现执行引擎、上下文绑定与性能优化；第四阶段补齐版本管理、灰度发布、监控告警等治理能力；第五阶段以完整项目串联，完成从规则编写到线上运行的全链路闭环。

1. 认知与设计：DSL定义、价值、场景、语法与语义设计。
2. 解析与编译：词法分析、语法分析、AST构建、类型校验、编译缓存。
3. 执行与优化：上下文模型、函数扩展、聚合窗口、短路求值、性能调优。
4. 治理与运维：版本、灰度、回滚、审计、监控、误杀复盘。
5. 综合实战：端到端实现一个可运行的风控规则引擎。

误区与复盘：新手最容易踩的四个坑