前言

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

正文

1. 先來個EF Core執行SQL演示

1.1 準備一個EF Core的項目

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

1.2 執行原生SQL

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

在操作數據庫時，執行如下SQL：

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

1.3 打印日志查看真正執行的SQL

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

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

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

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

2. FormattableString有點料

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

可以看到，FormattableString中包含拼接的字符串和對應的參數，拿到這些結果，就可以構造成想要的結果了。

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

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

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

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

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