使用dataContext.ExecuteCommand时，如何防范SQL注入并安全批量删除？

嘿，这个问题问得特别到位——刚接触数据操作时，很容易对“参数化查询到底安全在哪”存疑，我来给你拆解清楚：

先搞懂SQL注入的本质 #

SQL注入之所以能得逞，核心是恶意输入被当作SQL代码的一部分执行。比如如果有人把productId改成1; DROP TABLE ProductMedia--，要是你用字符串拼接写SQL：

// 危险！绝对不能这么写
dataContext.ExecuteCommand("DELETE FROM ProductMedia WHERE ProductId = " + productId);

数据库会把这段输入解析成两条SQL：DELETE FROM ProductMedia WHERE ProductId = 1，然后DROP TABLE ProductMedia--（--是注释，后面的内容被忽略），直接就把表删了。

你同事的写法为什么安全？ #

你同事给的dataContext.ExecuteCommand("DELETE FROM ProductMedia WHERE ProductId = {0}", productId);是参数化查询，这里的{0}不是字符串拼接的占位符，而是数据库能识别的参数占位符：

• 当你执行这段代码时，EF（假设是Entity Framework的DataContext）会把productId作为一个独立的参数传递给数据库，而不是把它拼进SQL字符串里。
• 数据库会把这个参数当作纯数据处理，不会解析成SQL代码的一部分。哪怕productId是恶意的字符串，数据库也只会把它当作ProductId字段的匹配值，不会执行额外的SQL命令。

简单说：参数化查询把“SQL代码结构”和“数据”彻底分开了，从根源上切断了注入的可能。

更安全（更推荐）的实现方式 #

虽然参数化SQL是安全的，但用ORM的原生API（比如LINQ）会更符合最佳实践，也更不容易出错：

// 用LINQ查询要删除的记录
var mediaRecords = dataContext.ProductMedia.Where(pm => pm.ProductId == productId);
// 批量删除
dataContext.ProductMedia.RemoveRange(mediaRecords);
// 提交更改
dataContext.SaveChanges();

这种方式的优势：

• 类型安全：编译时就能检查ProductId字段是否存在、类型是否匹配，避免手写SQL时的拼写错误。
• 完全无注入风险：LINQ会自动转换成参数化SQL，你根本不需要操心SQL拼接的问题。
• 可读性更强：用面向对象的方式操作数据，比手写SQL更直观，团队其他人也更容易理解代码逻辑。

额外注意事项 #

• 永远不要手动拼接SQL字符串传递参数，哪怕你觉得自己做了“转义”也不行——转义很容易有遗漏，参数化是唯一可靠的方式。
• 如果必须手写SQL（比如复杂查询），一定要用ORM提供的参数化方法（比如EF的ExecuteCommand、Dapper的Query带参数），不要自己拼接。

内容的提问来源于stack exchange，提问作者Yahtzei