前言

現(xiàn)在的項目，在操作數(shù)據(jù)庫的時候，我都喜歡用ORM框架，其中EF是一直以來用的比較多的;EF 的封裝的確讓小伙伴一心注重業(yè)務邏輯就行了，不用過多的關注操作數(shù)據(jù)庫的具體細節(jié)。但是在某些場景會選擇執(zhí)行SQL語句，比如一些復雜的插入或報表查詢等，其實不管用什么方式執(zhí)行SQL語句，防止SQL注入是必須的，所以就有了下面的討論。

正文

1. 先來個EF Core執(zhí)行SQL演示

1.1 準備一個EF Core的項目

關于EF Core在項目中的使用，之前分享了一篇很詳細的文章，這里就不重復說了，詳細內(nèi)容請看這里《跟我一起學.NetCore之EF Core 實戰(zhàn)入門，一看就會》。

1.2 執(zhí)行原生SQL

前提，已經(jīng)生成數(shù)據(jù)庫，并且有對應的表(以下只是模擬演示，并不是真實場景)：

在操作數(shù)據(jù)庫時，執(zhí)行如下SQL：

有很多小伙伴看到這時，應該也會懷疑這里會有SQL注入的風險，因為這里的SQL語句看上去就是一個拼接的字符串，只是用了插值運算符的形式，好像沒什么特別。

1.3 打印日志查看真正執(zhí)行的SQL

表面看上去的確會有風險，既然說沒有，那就拿出證據(jù)證明，直接把EF執(zhí)行過程的日志打印出來，看看真正執(zhí)行的SQL語句是什么樣子;

EF Core好像在5.0之后就提供了一個便捷的配置，可以方便的打印對應的SQL記錄，所以先來開啟日志打印功能：

開啟日志之后，執(zhí)行一下程序，看看執(zhí)行的真正SQL是什么樣的，控制臺可以看到如下日志：

可以看到，SQL語句已經(jīng)參數(shù)化了，所以是沒有注入風險的。那到底是為什么呢?因為ExecuteSqlInterpolatedAsync中的SQL語句參數(shù)的類型是FormattableString，EF Core內(nèi)部根據(jù)FormattableString結果，將對應的字符串生成參數(shù)化的SQL語句。

2. FormattableString有點料

為了看看FormattableString的作用，建一個簡單的控制臺程序，看看情況，如下：

可以看到，F(xiàn)ormattableString中包含拼接的字符串和對應的參數(shù)，拿到這些結果，就可以構造成想要的結果了。

2.1 var使用時還是要稍微注意一下

之前一個項目，因為var的使用，線上出現(xiàn)一個bug，挨個看了代碼感覺都沒問題，而且開發(fā)和測試環(huán)境正常，但在線上就是有問題，最后通過模擬線上數(shù)據(jù)調(diào)試才搞定。大概使用如下：

之所以開發(fā)和測試環(huán)境沒有問題，是沒有模擬全線上環(huán)境，所以讓這個bug漏掉了;對于開發(fā)來說，var用起來的確很是方便，但對于類似于上面的場景，使用具體的類型會避免一些不必要的Bug；

代碼比較簡單，就不提交了~~~

總結在開發(fā)過程中，稍微一個小細節(jié)的改動，可能效果就不一樣;同樣，一個小細節(jié)的忽視，就可能帶來一個很不好排查的Bug，所以小伙伴開發(fā)過程中，一定要注意哦!!!