PIVOT不支持变量列名，必须用动态SQL拼接并执行；需用STRING_AGG或FOR XML PATH配合QUOTENAME()安全生成列名，用sp_executesql参数化执行以防止注入、复用执行计划，并校验权限与空值。
PIVOT 本身不支持变量列名，硬写死列名的报表在真实业务中基本不可用；必须用动态 SQL 拼接执行，且拼接过程稍有不慎就会语法报错或注入风险。
为什么 PIVOT IN (@cols) 会直接报错？
SQL Server 解析器在语法检查阶段就拒绝变量出现在 IN 子句里。常见错误写法：PIVOT (SUM(Amount) FOR Category IN (@cols)) —— 报错信息通常是“必须是常量表达式”，根本不会进入执行环节。
真正能跑通的路径只有一条：把列名拼成字符串（如 '[North],[South],[East]'），再和整个 SELECT ... PIVOT 语句一起构造成纯文本，最后交给 sp_executesql 执行。
-
@cols必须是NVARCHAR类型，且拼接前要确保非空，否则IN ()语法非法 - 列名含空格、中文或特殊字符（如
]）时，不加QUOTENAME()会直接导致 SQL 崩溃 - 重复值会让
PIVOT报“列名重复”，拼接前必须加DISTINCT
如何安全拼出动态列名（兼容 SQL Server 2017+）？
推荐用 STRING_AGG(QUOTENAME(Category), ',')，它自动加方括号、转义特殊字符、且天然去重（配合 DISTINCT 更稳妥）。
低于 2017 版本需用 FOR XML PATH('')，但得手动处理开头逗号、NULL 值，且漏掉 QUOTENAME() 是高危操作——比如 Category = ']' 会提前闭合方括号，破坏整个语句结构。
- 示例拼接逻辑：
SELECT @cols = STRING_AGG(QUOTENAME(Category), ',') FROM (SELECT DISTINCT Category FROM Sales) t - 空结果集时
@cols为NULL，需提前判断：IF ISNULL(@cols, '') = '' RAISERROR('无有效列名', 16, 1) -
@sql变量必须声明为NVARCHAR(MAX)，否则超长会被截断（尤其列多时）
为什么必须用 sp_executesql 而不是 EXEC？
EXEC 只能传字符串，所有参数都得拼进 SQL 文本里，既不安全也不高效；sp_executesql 支持参数化绑定，是唯一合理选择。
- 执行计划可复用：相同结构的动态 SQL（仅参数值不同）能共用缓存计划，
EXEC每次都是全新编译 - 避免 SQL 注入：用户输入的
@Year等参数通过参数化传入，不参与字符串拼接 - 调用写法示例：
EXEC sp_executesql @sql, N'@year_param INT', @year_param = @Year -
@sql中写WHERE Year = @year_param，而不是WHERE Year = ' + CAST(@Year AS VARCHAR) + '
权限与兼容性容易被忽略的点
动态 PIVOT 在生产环境卡住，往往不是语法问题，而是权限或上下文问题。
- 存储过程执行者需有源表
SELECT权限，以及对sp_executesql的执行权限（通常默认有） - 若源数据来自视图或函数，确保执行上下文能访问它们；跨库查询必须用三段式名，如
db.schema.table -
QUOTENAME()返回的字符串长度上限是 128 字符，如果原始列名超长（比如自动生成的 GUID 别名），需先截断或映射
