对“引擎”二字的误解
引擎的本质
看了所谓的各种引擎，本质上只是为了解决一件事：能够在运行时，动态的走不同逻辑。
怎么解释呢？因为Java是静态的，代码写完了逻辑就不能调整了。比如对于两个金额，一会你想执行a+b，一会你想执行a-b，要怎么办呢？有人说你可以把运算符和a/b传给后端啊。那如果是a+(b-c)/d呢？
与其把这玩意拆开，还不如直接一个字符串丢给后端，后端爱咋玩咋玩。所以，所谓的表达式引擎就诞生了。
引擎的动机
为什么要这么做呢？很大一部分原因，是因为在简单场景下，可以让引擎的用户，（比如运营，风控）而不是让程序员来查看，并且决定（修改）业务流程。毕竟这件事情做业务的同学更专业，你老给人翻译业务需求也没什么价值。
这里为啥强调简单两个字，是因为很多自研的表达式引擎之粗制滥造，甚至连最简单的自定义函数的能力都没有，更不要说去实现异常处理、类型检查、高阶函数等等特性以及各种调优。
有些引擎作者会告诉你，我不需要这些，这个时候，如果你反问一句为什么不需要？
大概率他会楞了一下，然后开始闪烁其词。
正是因为大家对于引擎，想的太少，所以太多时候，这东西被设计成了一个表达式求值器。就是那种数学运算，加上if/else，可能前端再套一个基于antlr的解析器，就算成品了。
（作者甚至连什么叫BNF都不知道，因为好像他不需要知道啊。）
如果只是这样，Groovy难道它不香吗？
为什么通用化无法根本解决业务问题？
先回答上一个问题，Groovy它香，但是作为一门通用语言，它的业务表达能力太弱了。
所谓的语言表达能力，大家可以对比下对于按条件过滤并求和之流，用Java或者SQL来实现，代码的简洁性可以差多少。
SQL写的短，并不代表SQL有什么牛逼的，而是我们在用一种不公平的视角在比较。否则的话我可以反过来问，你能用SQL写个Web服务器么？
正是因为SQL本质上不是一门通用语言，因此，在特定领域，它的威力要远远大于Java。
说来说去，终于说到了正题上，一门通用的语言，并不能解决复杂业务场景下透出业务逻辑的问题，因为表达能力太弱，唯一能做的，无非是把开发人员的负担转嫁到了用户身上。
而且，你做一门语言，Debug不行，也没个IDE，就让人对着一个文本框在那写，这不是耍流氓是什么？
为什么会有这样的问题？
说到底，是有些人对于业务的理解过于浅薄了，或者说我真的就是想解决那一点点加减乘除的问题，（大概C语言课后习题的难度？），都觉得我可以在不理解业务的大背景下，做一个非常通用的工具，给很多人来使用。工具有多通用，就有多薄，就有让业务用起来有多痛苦。再说一句，Groovy它不香么？
虽然本质上，大家都想要让业务来决定业务逻辑，而且从一个业务无关的通用语言演化，确实也没有问题。真正的问题在于，工具的设计者，有没有深入理解过业务，并且带着一颗比较尊重业务的心来设计你的系统。而不是动不动就是，你这样的设计违背了我的初衷，我是要做通用引擎，不能给你做订制，你要follow我的标准。