前言
現在的專案，在運算元據庫的時候，我都喜歡用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綜藝圈”，和我一起學習吧。