参数化命令防SQL注入的根本原因是执行时机分离，即SQL结构编译时固定、参数值执行时绑定；显式声明参数类型更安全；不同数据库占位符不同；存储过程内动态拼接仍需参数化。
参数化命令让数据库把输入当“值”而不是“代码”
根本原因在于执行时机分离：SQL语句结构在编译阶段就已固定，参数值是在执行阶段才被绑定进去的。数据库引擎不会重新解析参数内容，哪怕里面是 ' OR '1'='1 或 ; DROP TABLE Users，也只会当作字符串字面量处理，不会参与语法树构建。
SqlCommand.Parameters.AddWithValue 不是万能的，类型推断可能埋雷
这个方法方便，但会根据传入的 .NET 值自动推断 SQL Server 类型（比如 string → varchar(8000)），容易引发隐式转换或截断。更稳妥的做法是显式指定类型：
cmd.Parameters.Add("@username", SqlDbType.NVarChar, 50).Value = username;cmd.Parameters.Add("@age", SqlDbType.Int).Value = age;
尤其对数字、日期、布尔字段，显式声明能避免因类型不匹配导致的查询失败或性能下降。
不同数据提供程序的参数占位符写法不统一
别只记 @param —— 它只对 System.Data.SqlClient（SQL Server）有效。换数据库就得改写法：
- OleDb / Odbc：用
?占位，按顺序绑定，不能用名字："SELECT * FROM Users WHERE Name = ? AND Age = ?" - Oracle：支持
:param或param（无冒号），但需注意驱动版本兼容性
混用时如果没按规则写占位符，ExecuteReader 会直接抛出 InvalidOperationException，错误信息里通常带“未提供参数值”之类提示，容易误判为逻辑问题。
存储过程中拼接 SQL 时，参数化照样失效
这是最容易忽略的盲区：即使调用的是存储过程，只要内部用了 EXEC(@sql) 或 sp_executesql 动态拼接，且拼接过程包含未经处理的用户输入，SQL 注入风险依然存在。例如：
CREATE PROCEDURE GetUserByName
@name NVARCHAR(50)
AS
BEGIN
DECLARE @sql NVARCHAR(MAX) = 'SELECT * FROM Users WHERE Name = ''' + @name + '''';
EXEC(@sql);
END
上面这段存储过程，无论外部怎么用参数调用，@name 进入拼接后仍会被解释为代码。真正安全的做法是：在动态 SQL 中继续用参数，例如用 sp_executesql 配合参数列表。
