必须拼时分两层：数据拼接用sp_executesql参数化，结构拼接靠白名单校验+QUOTENAME()；禁用EXEC(@sql)，严防SQL注入；多行拼接改用FOR XML PATH或STRING_AGG。
不能拼，就别拼；必须拼，就分两层——数据拼接用 sp_executesql 参数化，结构拼接（表名、列名）靠白名单 + QUOTENAME()。
拼数据？必须用 sp_executesql，别碰 EXEC(@sql)
只要字符串里混了用户输入（比如 @id、@name），又直接拼进 SQL，EXEC(@sql) 就等于给攻击者递刀。哪怕只拼一个数字，CAST(@id AS NVARCHAR) 进去也是拼接，不是参数化。
-
sp_executesql要三段式写全：SQL 字符串里只有占位符（如N'SELECT * FROM users WHERE id = @id'），第二段是类型声明（如N'@id INT'），第三段是@id = 123这种带等号的赋值 - 类型声明必须窄且明确：
NVARCHAR(50)不能写成NVARCHAR(MAX)，TINYINT别写成INT，否则可能隐式转换失败或扩大攻击面 - 漏掉
@param = value中的@param =前缀，或顺序错位，轻则查不到，重则报错中断
拼表名/列名？白名单校验比 QUOTENAME() 重要十倍
QUOTENAME(@table_name) 只防单引号，防不了 ]; DROP TABLE x; -- 这类结尾注入。它只是最后一道封装，不是校验逻辑。
- 先查系统视图确认存在：
IF NOT EXISTS (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) THROW 50000, 'Invalid table name', 1; - 排序字段、筛选字段这类动态语法成分，必须硬编码白名单：
IF @sort_col NOT IN ('created_at', 'status', 'amount') THROW 50000, 'Invalid sort column', 1; - 别用
OBJECT_ID(@table_name)单独判断——它不校验 schema，恶意输入可能被截断后误判
拼多行结果？别在循环里用 +，改用 FOR XML PATH('') 或 STRING_AGG
在 WHILE 或游标里写 @result = @result + 'xxx' 是 CPU 飙升的典型原因：每次拼接都触发内存重分配和隐式转换，复杂度 O(n²)。
- 集合拼接统一走
STUFF((SELECT ',' + col FROM t FOR XML PATH(''), TYPE).value('.', 'NVARCHAR(MAX)'), 1, 1, '')—— 必须加TYPE和.value()，否则&、会被转义 -
ORDER BY必须写在子查询内，外层ORDER BY对拼接顺序无效 - SQL Server 2017+ 优先用
STRING_AGG(col, ',') WITHIN GROUP (ORDER BY sort_col)，但注意：NULL 值默认被跳过，得先ISNULL(col, '')包一层 - 别试图用版本判断在同一个存储过程中混用两种写法——编译期就会报错，
IF @@VERSION LIKE '%2017%'包STRING_AGG在 2016 上直接编译失败
真正容易被忽略的点是：参数声明本身就要防绕过。声明 @user_id NVARCHAR(MAX) 再怎么参数化也白搭；而 IF @user_id > 999999 RETURN 这类硬约束，比任何拼接技巧都管用。
