sp_executesql仅支持值参数化，不支持标识符（如列名、排序方向）参数化，故order by @sortcol @direction等必须拼接；安全做法是白名单校验+quotename()包裹对象名+case处理排序逻辑。
存储过程本身不能自动防SQL注入，关键看你怎么写——只要在过程里拼接用户输入的表名、列名或排序方向，sp_executesql 的参数化就完全失效。
为什么 sp_executesql 的 @params 不能保护列名和排序方向？
SQL Server 的 sp_executesql 只对值（value）做参数化，不处理语法结构。比如 @sortcol 是列名，@direction 是 'asc' 或 'desc'，它们出现在 ORDER BY @sortcol @direction 中时，数据库必须在编译前就知道这些是标识符还是关键字，所以只能靠字符串拼接。
- 拼接
@sortcol：直接用+' '+@sortcol就等于把用户输入当 SQL 代码执行 - 拼接
@direction：如果没校验，攻击者传入'desc; WAITFOR DELAY ''0:0:5''; --'就能盲注 -
QUOTENAME()是唯一安全的标识符包裹方式，但只适用于单个对象名（如表、列），不能用于表达式或关键字
如何安全处理动态 ORDER BY 和 TOP N？
白名单 + CASE 是最可靠的做法，避免任何字符串拼接。
- 对排序字段：用
CASE @sortcol WHEN 'name' THEN name WHEN 'email' THEN email END，再统一加ASC/DESC - 对排序方向：单独判断
@direction，只接受'asc'或'desc'，其他一律报错或默认 - 对
TOP：用TOP (@topcount)是安全的（SQL Server 2005+），但注意@topcount必须是INT类型，不能是字符串 - 别用
EXEC('SELECT TOP '+@n+' ...')—— 这种写法连QUOTENAME都救不了
哪些地方必须用 QUOTENAME()？
所有用户可控、且要作为对象名（表、列、schema）参与拼接的地方，QUOTENAME() 是强制操作，不是可选项。
- 拼接表名：
'SELECT * FROM ' + QUOTENAME(@tablename)，否则@tablename = '] DROP TABLE users; --'会直接执行 - 拼接列名：
QUOTENAME(@colname)，因为列名可能含空格或特殊字符，不加会语法错误 - 慎用嵌套：
QUOTENAME(QUOTENAME(@schemaname) + '.' + QUOTENAME(@tablename))是错的，QUOTENAME只作用于单个标识符 -
QUOTENAME(@input, '''')是无效用法 —— 第二个参数只能是单字符分隔符，如'['或'"'，不能是单引号
最容易被忽略的是权限上下文：即使你用了 QUOTENAME 和白名单，如果存储过程以 db_owner 身份运行，而调用者本不该删表，那一次拼接失误就会让整个库裸奔。务必用最小权限账户部署存储过程，而不是靠“我代码很安全”来掩盖权限设计缺陷。
