FOR XML PATH必须嵌套在子查询中，因SQL Server禁止在GROUP BY同级使用FOR XML，否则报“无法对包含聚合或FOR XML的表达式执行GROUP BY”；外层GROUP BY、内层子查询拼接，并通过别名关联字段。
FOR XML PATH 不能直接在 GROUP BY 外层拼接多列，必须用子查询嵌套；否则报错“无法对包含聚合或 FOR XML 的表达式执行 GROUP BY”。
为什么 FOR XML PATH 必须写在子查询里
SQL Server 不允许在同一个 SELECT 语句中既做 GROUP BY 聚合，又在同级使用 FOR XML PATH。它会把 FOR XML 当作“不可聚合的表达式”直接拒绝编译。
- 错误写法：
SELECT GroupName, FuncationName + ',' FROM #Temp GROUP BY GroupName FOR XML PATH('')→ 报错Incorrect syntax near 'FOR' - 正确结构：外层只做
GROUP BY，内层子查询负责拼接，靠关联字段（如TA.GroupName = TB.GroupName）桥接 - 子查询必须有别名（比如
AS Sub），否则外部引用字段会失败 - 若不加别名，SQL Server 会提示
The multi-part identifier "b.age" could not be bound
如何安全拼接含 NULL 或特殊字符的字段
字段值为 NULL 时，',' + col 整体变 NULL；含 &、、" 时，漏处理会触发 XML 解析失败，报错 XML parsing: line 1, character xx, illegal name character。
- NULL 处理：统一用
ISNULL(col, '')或COALESCE(col, '')包一层，再拼接 - 特殊字符处理：必须加
TYPE和.value('.', 'NVARCHAR(MAX)')，例如：(SELECT ',' + ISNULL(name, '') FROM Student a WHERE a.age = b.age FOR XML PATH(''), TYPE).value('.', 'NVARCHAR(MAX)') - 漏掉
TYPE就等于裸字符串拼接，&可能变成&后续解析崩 - 目标变量声明务必用
VARCHAR(MAX)或NVARCHAR(MAX)，VARCHAR(100)会静默截断
STUFF 去首分隔符的参数怎么设才稳
用 STUFF 删开头逗号最常见，但起始位置和长度写错会导致空结果出错或删错内容。关键是：拼接前缀必须固定且唯一，否则 STUFF 无法准确定位。
- 推荐写法：
STUFF((SELECT ',' + col ... FOR XML ...), 1, 1, '')—— 前缀是单个逗号，删 1 位最安全 - 如果用了
', '（逗号+空格），就得写STUFF(..., 1, 2, '')，否则空格残留 - 避免用
LEFT(..., LEN(...) - 1)：当子查询无结果时，LEN(NULL)是NULL，整个表达式崩成NULL - ORDER BY 必须写在子查询内部，外层
ORDER BY对拼接顺序完全无效
SQL Server 2017+ 应该优先用 STRING_AGG 吗
应该，但不是无脑替换。STRING_AGG 语义清晰、性能更好、不依赖 XML 引擎，但它在存储过程中容易因忽略排序或 NULL 处理翻车。
- 必须显式排序：
STRING_AGG(col, ',') WITHIN GROUP (ORDER BY sort_col)，括号不能丢 - NULL 默认被跳过（不是留空），要显示为空字符串得先
COALESCE(col, '') - 分隔符不能为空字符串字面量，得写
SEPARATOR ''，写成SEPARATOR NULL或省略会报错 - 跨版本兼容场景（比如存储过程要跑在 2016 和 2022 上），不能靠
IF @@VERSION动态拼 SQL——语法校验阶段就报错，得用两个独立分支或视图抽象
真正容易被忽略的是：FOR XML PATH 的拼接顺序在并行执行下完全不可控，没写 ORDER BY 的子查询，今天结果对，明天可能乱序；而 STRING_AGG 的 WITHIN GROUP 是强制语法，不写直接编译失败——这点反而更可靠。
