直接拼接字符串导致sql注入，因为用户输入被当作sql代码执行而非数据；如输入' or '1'='1'使查询条件恒真，绕过认证。根本原因是未区分“代码”与“数据”。
为什么直接拼接字符串会导致SQL注入
因为用户输入的内容会原样嵌入到 SQL 语句中，数据库不区分“代码”和“数据”。比如用户在登录框输入 ' OR '1'='1，拼接后变成 SELECT * FROM Users WHERE username = '' OR '1'='1' AND password = 'xxx'，整个条件恒真，绕过认证。
根本问题是：把数据当成了 SQL 语法的一部分。解决思路只有一个——让数据库明确知道哪部分是值、哪部分是结构。
SqlParameter 是怎么切断注入链路的
SqlParameter 把值单独传给 SQL Server，由数据库引擎在执行阶段才绑定，而不是在解析 SQL 文本时就混进去。哪怕你传入 Robert'; DROP TABLE Students; --，它也只会被当作一个字符串值处理，不会触发语句切割。
关键点：
-
SqlParameter必须配合SqlCommand的Parameters集合使用，不能只 new 一个对象就完事 - 参数名要和 SQL 中的占位符严格匹配（如
@name对应cmd.Parameters.Add("@name", ...)） - 类型最好显式指定（比如
SqlDbType.NVarChar），避免隐式转换引发截断或性能问题
示例：
string sql = "SELECT * FROM Users WHERE Username = @username AND PasswordHash = @hash";
using (var cmd = new SqlCommand(sql, conn))
{
cmd.Parameters.Add("@username", SqlDbType.NVarChar).Value = userInputName;
cmd.Parameters.Add("@hash", SqlDbType.VarChar).Value = hashedPwd;
// 执行查询...
}
常见错误写法与对应风险
这些看似“用了参数”，实则仍可能出问题：
- 用字符串拼接构造表名/列名：
"SELECT * FROM " + tableName + " WHERE id = @id"——tableName无法用SqlParameter绑定，必须走白名单校验或QUOTENAME() - 参数名写错或漏加：
cmd.Parameters.Add("@user", ...)但 SQL 里写的是@username—— 查询返回空，但不会报错，容易误判为“没数据”而非“参数未生效” - 用
AddWithValue自动推断类型：cmd.Parameters.AddWithValue("@id", "123")可能被识别为VarChar而非Int，导致索引失效或隐式转换 - 在存储过程中调用时忽略参数顺序：如果存储过程定义是
@a int, @b nvarchar(50)，但 C# 中先 add@b再 add@a，且没写参数名 —— 位置错乱，值传错字段
除了 SqlParameter，还有哪些必须同步做的
防注入不是单点任务，SqlParameter 解决了最核心的数据绑定问题，但还有几个硬性配套动作：
- 连接字符串不能包含用户可控内容（比如从配置文件读取时，别让用户能改 appSettings 键名）
- 所有动态 SQL 片段（如 ORDER BY 字段、WHERE 条件组合）必须通过白名单校验，例如：
if (!new[] { "Name", "Email", "CreatedTime" }.Contains(sortField)) throw ... - 数据库账号权限最小化：应用账号只授予
SELECT/INSERT/UPDATE必需表，禁用EXECUTE、CREATE等高危权限 - 开启 SQL Server 的
PARAMETERIZATION FORCED（仅适用于简单查询场景），作为额外兜底，但不能替代参数化编码
真正难的不是写对那一行 Add()，而是整个数据流里没有一个环节把用户输入当成 SQL 片段去拼接 —— 这个意识比语法更重要。
