STRING_AGG 是 SQL Server 2017+ 原生聚合函数，执行高效且支持声明式 ORDER BY；FOR XML PATH 是兼容旧版本的间接方案，需 XML 序列化/反序列化、隐式转换多，排序不可靠且易出错。
STRING_AGG 是原生聚合函数，FOR XML PATH 是“曲线救国”
STRING_AGG 从 SQL Server 2017 起就是内置聚合运算符，执行计划里直接走聚合节点（Aggregate），引擎能做向量化处理、内存预分配和分段缓冲。而 FOR XML PATH 本质是先生成 XML 类型中间结果（哪怕空标签），再用 STUFF 和 .value() 做文本提取——多了一次类型转换、一次 XML 序列化/反序列化、一次字符串截断操作。
常见错误是只看语句长度，误以为 STRING_AGG(name, ', ') 和 STUFF((SELECT ','+name FOR XML PATH('')), 1, 1, '') 等价；实际上后者在执行时会触发额外的隐式转换（比如把 NULL 转成空字符串再拼接），且无法被查询优化器内联优化。
ORDER BY 在 STRING_AGG 中是声明式语法，FOR XML PATH 中是隐式依赖
WITHIN GROUP (ORDER BY ...) 是 STRING_AGG 的合法子句，排序逻辑由聚合阶段统一完成，不产生额外嵌套查询。而 FOR XML PATH 若想保序，必须在外层或子查询中显式加 ORDER BY，但 SQL Server 不保证子查询里的 ORDER BY 一定生效（除非配合 TOP (2147483647) 或 OFFSET 0 ROWS）。
容易踩的坑：
- 写成
SELECT STUFF((SELECT ','+name FROM t ORDER BY id FOR XML PATH('')), 1, 1, '')→ 排序可能被忽略，结果随机 - 漏掉
TYPE和.value()→ 特殊字符如&、被转义成 <code>&、< - 没加关联条件（如
WHERE t2.dept = t1.dept）→ 子查询变成笛卡尔积级拼接，性能断崖下跌
NULL 处理和分隔符行为更可控
STRING_AGG 默认跳过 NULL，且允许你在聚合前用 ISNULL 或 COALESCE 统一兜底，比如 STRING_AGG(ISNULL(email, '(none)'), '; ')。而 FOR XML PATH 对 NULL 的处理取决于拼接表达式：',' + NULL 整个结果变 NULL，必须写成 ',' + ISNULL(email, '') 才安全。
分隔符方面：STRING_AGG 第二参数必须是字符串字面量或变量（',' 合法，, 报错）；FOR XML PATH 则靠手拼，容易漏空格、多逗号、或在开头/结尾残留分隔符，得靠 STUFF 硬删——这步本身就有字符串重分配开销。
兼容性之外，别低估执行计划差异
在 2019+ 版本上跑相同逻辑，STRING_AGG 的执行计划通常少一层 Nested Loops，CPU 时间平均低 15%~30%，尤其当每组行数超过 100 行时优势更明显。不过要注意：如果数据库兼容级别设为 140（SQL Server 2017）以下，STRING_AGG 直接不可用，报错 Invalid usage of the option WITHIN GROUP in the STRING_AGG function 或更早的语法错误。
真正容易被忽略的是：即便用了 STRING_AGG，如果忘记 GROUP BY 或写错分组字段，它不会像普通函数那样返回单值，而是报错 STRING_AGG is not allowed in the context——这个上下文限制比多数人想象得更严格。
