唯一可靠路径是严格使用 SqlParameter 替代字符串拼接，所有用户输入必须进参数，表名列名等动态结构须白名单校验，AddWithValue 须禁用并显式指定类型与长度。
用 SqlParameter 替代字符串拼接是唯一可靠路径
直接拼接用户输入到 CommandText 中，无论加不加引号、转不转义，都挡不住 SQL 注入。C# 的 SqlCommand 本身不提供“重写执行逻辑”的钩子——它没开放底层解析或预处理流程。所谓“全面杜绝”，只能靠严格使用参数化查询，而非试图改造执行过程。
常见错误现象：string sql = $"SELECT * FROM Users WHERE Name = '{name}'";，哪怕 name 是 "admin' --"，也会让注释掉后续条件；更隐蔽的是 Unicode 同形字、宽字节截断（虽在现代 .NET 中极少见，但依赖编码层过滤仍是幻觉）。
- 所有用户可控输入（含 URL 参数、表单字段、HTTP Header、文件内容）必须进
SqlParameter - 不要用
string.Format、$"..."或StringBuilder拼接 SQL 主体结构 - 表名、列名、排序字段等无法参数化的部分，必须白名单校验（如
new[] { "Name", "Email", "CreatedAt" }.Contains(sortBy)）
AddWithValue 看似方便，实则埋雷
AddWithValue 会根据传入的 C# 值自动推断 SQL Server 类型，但推断常出错：比如传 null 推成 int，传 "123"（字符串）推成 varchar(3)，导致索引失效或隐式转换失败。它不解决注入，反而增加运行时不确定性。
正确做法是显式指定类型和长度：
cmd.Parameters.Add(new SqlParameter("@userId", SqlDbType.Int) { Value = userId });
cmd.Parameters.Add(new SqlParameter("@email", SqlDbType.NVarChar, 256) { Value = email ?? DBNull.Value });- 对可空值，显式赋
DBNull.Value，别依赖AddWithValue的 null 处理 - 字符串参数务必指定长度（如
NVarChar(256)），避免 SQL Server 用默认长度（通常是 1）引发截断或计划缓存污染 - 数值类型优先用
SqlDbType.Int、SqlDbType.DateTime2等精确类型，不用SqlDbType.Variant
动态 SQL 场景下如何安全拼接 WHERE 条件
当搜索条件完全由前端控制（如多字段组合筛选），不能因为“要拼接”就放弃参数化。核心原则：SQL 结构（关键字、字段名、运算符）走白名单，值全部进参数。
将任意网站转换为文件系统，自动抓取网站并将页面挂载为 Markdown 文件，可使用 grep、diff、cat 等标准 Unix 命令进行搜索、比较、读取和浏览。
错误示范：WHERE " + fieldName + " LIKE '%" + keyword + "%' —— 字段名和关键词全失控。
正确思路：
var conditions = new List<string>();
var parameters = new List<SqlParameter>();
<p>if (!string.IsNullOrWhiteSpace(name)) {
conditions.Add("Name LIKE @name");
parameters.Add(new SqlParameter("@name", SqlDbType.NVarChar, 100) { Value = "%" + name + "%" });
}
if (minAge > 0) {
conditions.Add("Age >= @minAge");
parameters.Add(new SqlParameter("@minAge", SqlDbType.Int) { Value = minAge });
}</p><p>cmd.CommandText = "SELECT * FROM Users WHERE " + string.Join(" AND ", conditions);
cmd.Parameters.AddRange(parameters.ToArray());- 字段名、操作符（
LIKE、=、BETWEEN）必须来自预设集合，不可来自请求原始值 - 每个动态条件对应一个独立参数，不复用参数名
- 避免在参数值中拼接通配符（如
"%" + value + "%"）——这属于业务逻辑，不是注入点，但需注意 NVarChar 长度是否覆盖完整值
存储过程调用也不能绕过参数化
有人误以为“调用存储过程就天然防注入”，其实不然。如果在 SP 内部用 EXEC(@sql) 或 sp_executesql 拼接动态 SQL，且参数未通过 @param 传入，照样中招。而从 C# 调用 SP 时，仍必须用 SqlParameter 传参，不能拼接 CommandText 为 "EXEC SearchUsers '" + name + "'"。
正确方式：
cmd.CommandType = CommandType.StoredProcedure;
cmd.CommandText = "SearchUsers";
cmd.Parameters.Add(new SqlParameter("@name", SqlDbType.NVarChar, 100) { Value = name });- 存储过程本身若含动态 SQL，其内部也必须用
sp_executesql+ 参数化，禁用EXEC(@sql) - C# 层传参时，仍需检查参数类型和长度匹配 SP 定义，否则可能触发隐式转换或截断
- 不要为了“省事”把整个 JSON 字符串传给 SP 再解析——这等于把注入战场转移到 T-SQL 层
真正难的不是写对那几行 Parameters.Add，而是守住边界：任何外部输入进入 SQL 上下文前，必须经过参数化或白名单校验。没有中间路线，也没有“基本安全”的妥协方案。
