對“引擎”二字的誤解
引擎的本質
看了所謂的各種引擎，本質上只是爲了解決一件事：能夠在運行時，動態的走不同邏輯。
怎麼解釋呢？因爲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我的標準。