前言
現在的項目，在操作數據庫的時候，我都喜歡用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.2 打印日志查看真正執行的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，所以小伙伴開發過程中，一定要注意哦！！！
關注“Code綜藝圈”，和我一起學習吧。