存储过程本身不防sql注入，关键在是否安全编写；必须用sp_executesql参数化隔离数据与sql结构，动态对象名需白名单校验，参数类型须窄且强校验，隐性拼接点同样危险。
存储过程本身不防SQL注入——只要内部拼接用户输入，或调用端没走参数化，漏洞照旧存在。
sp_executesql 用错等于白用
很多人以为用了 sp_executesql 就安全了，其实只写对一半照样中招。它只是工具，关键看参数是否真正隔离。
- 危险写法：
EXEC sp_executesql N'SELECT * FROM users WHERE name = ''' + @name + '''—— 字符串拼接发生在 SQL 模板里，@name的值早被吞进语句体，参数化形同虚设 - 正确写法：SQL 模板里只留
@param占位符，类型声明字符串必须完整（如N'@name NVARCHAR(50)'），调用时明确绑定（@name = @input） - 漏掉类型声明、类型太宽（比如用
SQL_VARIANT或NVARCHAR(MAX)）、参数名和变量名不一致，都会让绕过变简单
表名、列名、ORDER BY 字段不能参数化
SQL Server 不允许把 @table_name 当作参数插进 FROM 或 ORDER BY 后面——硬拼就是高危点，QUOTENAME() 只能防单引号，挡不住 ]; DROP TABLE logs; -- 这类结尾注入。
- 必须用白名单校验：
IF @sort_col NOT IN ('created_at', 'status', 'email') THROW 50000, 'Invalid sort column', 1 - 查系统视图确认对象归属：
SELECT 1 FROM sys.tables t JOIN sys.schemas s ON t.schema_id = s.schema_id WHERE s.name = 'dbo' AND t.name = @table_name - 别信
OBJECT_ID(@table_name)单独判断——它不校验 schema，恶意输入可能被截断后误判
调用端拼字符串，存储过程再安全也白搭
存储过程是安全载体，不是防弹衣。如果应用层用字符串拼接方式调用，比如 C# 写 "EXEC GetUser @name = '" + input + "'"，那数据库里定义的 @name NVARCHAR(50) 完全失效——恶意输入在抵达存储过程前就被注入进执行语句了。
- 必须用
SqlCommand.Parameters.Add()、PreparedStatement.setXXX()等绑定方式 - MyBatis 中
${}是原样替换，#{}在存储过程调用上下文中通常不生效（整个EXEC被当作文本发给数据库） - PHP 的
mysqli_query("CALL sp_login('$user', '$pass')")和 Java 的Statement.execute("CALL login('" + user + "', '" + pass + "')")全部高危
最常被忽略的是隐性拼接点：日志记录里把参数转成字符串再拼进 INSERT、触发器里读 CONTEXT_INFO 后构造 SQL、甚至用 OPENROWSET 动态连远程库——这些地方不显眼，但一旦混入用户输入，就是注入入口。
