SqlParameter能防SQL注入，因其不拼接字符串而是将值作为独立数据由数据库引擎绑定，严格区分代码与数据；错误拼接、动态对象名或IN列表滥用会使防护失效。
SqlParameter 为什么能防 SQL 注入
因为 SqlParameter 不拼接字符串，而是把值作为独立数据传给 SQL Server，由数据库引擎在执行前绑定参数、区分“代码”和“数据”。哪怕你传入 "'; DROP TABLE Users; --"，SQL Server 也只会把它当做一个普通字符串值处理，不会解析成语句的一部分。
关键前提是：值必须**全程不经过字符串拼接**，且参数名/类型/顺序与 SQL 中的占位符严格匹配。
写法错误导致防注入失效的典型场景
下面这些操作会让 SqlParameter 形同虚设：
- 用
string.Format或$"..."拼接 SQL，再把参数塞进去 —— 比如$"SELECT * FROM Users WHERE Name = '{name}'"，此时加SqlParameter已无意义 - 把表名、列名、排序字段（如
ORDER BY {sortColumn}）当成参数传 ——SqlParameter**不支持**动态对象名，只能用于值（WHERE条件、INSERT值、UPDATE赋值右值等） - 手动拼接
IN列表，比如"WHERE Id IN ({idsCsv})"，然后试图用一个SqlParameter绑定逗号分隔字符串 —— 数据库不识别这种格式，必须展开为多个参数或改用表值参数
正确使用 SqlParameter 的实操要点
核心原则：SQL 字符串里只出现 @paramName 占位符，所有动态值均由 SqlParameter 提供，且不参与任何字符串构造。
示例（安全写法）：
string sql = "SELECT * FROM Users WHERE Status = @status AND CreatedAt > @since";
using var cmd = new SqlCommand(sql, conn);
cmd.Parameters.Add(new SqlParameter("@status", "Active"));
cmd.Parameters.Add(new SqlParameter("@since", DateTime.Today.AddDays(-7)));
// 或更简洁地：
// cmd.Parameters.AddWithValue("@status", "Active"); // 注意：AddWithValue 有隐式类型推断风险，见下条
- 优先用
new SqlParameter("@name", value)显式构造，避免AddWithValue对string推断为nvarchar(1)导致索引失效 - 对可空类型（如
int?），显式传DBNull.Value，不要传null（否则可能触发装箱异常或隐式转换） - 批量操作时，避免循环中反复 new SqlCommand；可复用
cmd.Parameters.Clear()+ 重新 Add，但注意参数顺序需一致
动态列/表名这类真·无法参数化的情况怎么办
这类需求本质无法用 SqlParameter 解决，必须换思路：
- 白名单校验：把允许的列名硬编码在数组里，用
Array.Contains判断输入是否合法，再拼接 - 引用标识符：用
SqlCommandBuilder.QuoteIdentifier("UserCount")包裹用户输入的列名，防止注入（但仅限于标识符，不能代替参数防数据注入） - 改用存储过程 +
EXEC sp_executesql：在存储过程中先校验对象名，再拼接并用内部参数化 —— 把风险收束到 DB 层可控范围内
记住：只要 SQL 字符串里出现了用户输入的原始文本，就已脱离 SqlParameter 的保护范围，必须靠校验、转义或架构设计兜底。
