前言

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

正文

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

1.1 準(zhǔn)備一個EF Core的項目

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

1.2 執(zhí)行原生SQL

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

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

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

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

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

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

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

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

2. FormattableString有點(diǎn)料

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

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

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

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

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

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

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