SqlCommand+Parameters.Add()是唯一防SQL注入的可靠做法，必须对所有用户输入使用参数化查询，而非字符串拼接；参数化仅保护数据值，表名列名等结构需白名单校验。
用 SqlCommand + Parameters.Add() 是唯一靠谱做法
硬拼接字符串（比如 "SELECT * FROM Users WHERE Name = '" + name + "'"）等于给黑客递刀。C# 的 SqlCommand 本身不防注入，真正起作用的是你是否把用户输入塞进 Parameters 集合——不是靠转义、不是靠过滤，是靠 SQL Server（或其它数据库）底层把参数值当纯数据处理，彻底剥离执行语义。
常见错误现象：SqlException 提示“在期待条件的附近有语法错误”，其实是拼出来的 SQL 已被恶意闭合引号或插入 OR 1=1；更隐蔽的是时间盲注，表面没报错但行为异常。
- 永远不用
string.Format或$"..."拼接 SQL 中的用户输入 - 所有外部输入（
Request.QueryString、TextBox.Text、API body）都必须走Parameters - 即使输入是数字，也别用
Convert.ToInt32()后直接拼字符串——绕过类型检查后仍可能被注入（比如传入1; DROP TABLE Users--）
SqlParameter 的 Value 和 DbType 怎么设才安全
只加参数名不够，Value 必须是原始输入（不做任何字符串替换），而 DbType 建议显式指定。不设 DbType 时，ADO.NET 会自动推断，但推断逻辑依赖值本身——空字符串可能被当成 VarChar，null 可能被当成 Object，某些驱动下甚至触发隐式转换漏洞。
使用场景：查询用户名、分页取数、带日期范围的报表导出——只要 SQL 里有变量占位，就得对应一个 SqlParameter。
- 用
new SqlParameter("@name", SqlDbType.NVarChar) { Value = userName }，而不是new SqlParameter("@name", userName) - 对可能为 null 的字段，直接赋
Value = (object)userName ?? DBNull.Value，别用""替代 null - 日期类型务必用
SqlDbType.DateTime2（而非DateTime），避免 SQL Server 2005 以下版本精度截断引发意外匹配
存储过程调用也得参数化，别信“它自己安全”
很多人以为调用存储过程就天然免疫注入，其实错得很彻底。如果存储过程中用了 EXEC(@sql) 或 sp_executesql 且拼接了参数，照样中招。C# 层调用时若用 CommandType.StoredProcedure 却仍手动拼接过程名或参数列表，风险一样存在。
错误示例：cmd.CommandText = "exec SearchUsers '" + keyword + "'"; —— 这根本没用上存储过程的安全机制。
- 调用存储过程必须设
cmd.CommandType = CommandType.StoredProcedure - 过程名写死在
CommandText里，如cmd.CommandText = "SearchUsers"，绝不能拼接 - 所有传入参数一律走
Parameters.Add()，哪怕过程内部只是简单WHERE Name = @keyword
ORM 框架（比如 EF Core）不是免检金牌
EF Core 的 LINQ 查询默认参数化，但一旦你用 FromSqlRaw() 或 ExecuteSqlRaw()，就立刻回到手写 SQL 的风险区。很多人在分页、动态排序、复杂 JSON 查询时掉进这个坑，以为 “EF 在用，所以安全”，结果 FromSqlRaw("SELECT * FROM Posts WHERE Category = '" + cat + "'") 直接暴露。
性能影响：参数化本身几乎无开销，SQL Server 还能复用执行计划；但滥用 FromSqlInterpolated（带 $ 插值）时，EF 会尝试解析插值表达式——解析失败就退化成字符串拼接，此时连编译期警告都没有。
- 禁用
FromSqlRaw和ExecuteSqlRaw，改用FromSqlInterpolated并确保所有变量都在{}内（如FromSqlInterpolated($"SELECT * FROM Posts WHERE Category = {cat}")） - 自定义 SQL 中要拼表名或列名（非数据值）？必须白名单校验，不能靠参数化——参数化只管数据，不管结构
- Dapper 同理：
connection.Query<t>("SELECT * FROM Users WHERE Id = @id", new { id = userId })</t>安全；但new { sql = $"SELECT * FROM {tableName}" }就是雷
最容易被忽略的点：参数化只保护「数据值」，不保护 SQL 结构本身。表名、列名、排序字段、分页偏移量（OFFSET @skip ROWS 是安全的，但 ORDER BY @sortColumn 不行）这些都得靠白名单或枚举约束，否则再规范的参数化也救不了。
