跳到主要内容

表达式

表达式适合在低代码配置中承接短小、可读、低副作用的动态计算。它通常用于“根据当前上下文快速取值或判断”，而不是承接一整段复杂逻辑。

什么时候用表达式​

  • 需要根据当前记录、当前用户或当前上下文计算一个值
  • 需要写简单条件判断、拼接或格式转换
  • 希望规则保持短小，业务人员能直接读懂

如果逻辑已经涉及多步处理、循环、复杂分支或明显的副作用，通常应转向 脚本 或 逻辑流。

常见使用位置​

  • 字段默认值或动态取值
  • 条件判断与分支配置
  • 需要在配置中内联少量计算逻辑的场景

你通常还需要一起看什么​

先理解表达式的运行方式​

当前平台表达式基于 SpEL，使用 ${...} 作为模板入口。

这意味着它有几个特点：

  1. 表达式本质上是“在一个上下文里取值和计算”。
  2. 上下文对象是只读聚合的，适合短计算，不适合复杂流程控制。
  3. 对不存在的属性访问，当前实现通常会返回 null，而不是立刻因为属性不存在而中断。

所以表达式更像“配置里的动态取值语法”，不是迷你脚本语言。

表达式里通常会直接用什么​

最常见的是：

  • AuthenticationHolder
  • OrganizationHolder
  • Dates
  • Converter
  • codeGen

具体对象和方法，继续看 表达式上下文。

典型用法​

默认值或动态拼接​

${Dates.format(T(java.time.LocalDateTime).now(), 'yyyy-MM-dd')}

条件判断​

${AuthenticationHolder.getPrincipal() == 'admin'}

编码预览或生成​

${codeGen.peek('ORDER-{yyyyMMdd}-<0001>')}

不同宿主页面还可能注入自己的业务变量，例如当前记录、当前表单值等；这部分要以具体页面或模型场景为准。

什么时候该从表达式升级​

出现下面任一情况时，通常就不该继续堆表达式了：

  • 已经需要中间变量
  • 已经需要日志输出
  • 已经需要循环或多步处理
  • 已经需要解释半天别人才能看懂

这时优先转到：

使用建议​

  • 让表达式保持“看一眼就能懂”的长度
  • 优先复用现成上下文能力，例如日期、类型转换和编码生成
  • 当一条规则开始需要解释很多上下文时，就应该考虑改成脚本或节点

排查建议​

如果表达式没有按预期工作，优先按下面顺序查：

  1. 当前宿主位置是否真的支持 ${...}。
  2. 表达式里引用的对象是否在 表达式上下文 中存在。
  3. 是否把复杂脚本语法误写成了表达式。
  4. 是否访问了一个实际为 null 的上下文对象或字段。

常见坑​

  • 把表达式写成一大串业务逻辑，最终可读性比脚本还差。
  • 误以为表达式能直接完成复杂副作用操作。
  • 看到属性访问返回 null，却误以为表达式根本没有执行。