同事都提防SQL注入隐患，我偏信无此风险？

本文共计898个文字，预计阅读时间需要4分钟。

前言：现在的项目，在操作数据库的时候，我都喜欢用ORM框架，其中EF是一个直接以来使用的比较多的。EF的封装的确实让小伙伴一心注重业务逻辑就行了，不用过多关注数据库的具体操作细节。

前言

现在的项目，在操作数据库的时候，我都喜欢用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语句。