for xml path('') 本质是 xml 序列化机制，非字符串拼接工具；直接使用会因非法 xml 字符（如&abc）触发解析错误，必须加 type + .value() 解包、stuff 外层包裹去首分隔符、order by 显式置于子查询内才能安全可靠拼接。
因为 FOR XML PATH 本质不是字符串拼接工具，而是 XML 序列化机制的“副产品”——它在低版本 SQL Server 中能用，但每一步都藏着类型、转义、顺序三重陷阱，稍有疏忽就报错或结果错乱。
为什么直接 FOR XML PATH('') 会报 XML parsing: line 1, character xx, illegal name character
SQL Server 在执行 FOR XML PATH('') 时，会先尝试把拼接内容当作 XML 片段解析。遇到字段含 &abc、、未闭合引号等不构成合法 XML 实体的片段，就会在校验阶段直接崩掉。
- 错误写法：
SELECT name + ',' FROM sys.tables FOR XML PATH('')—— 某个表名是Report&Analytics就触发报错 - 正确写法必须加
TYPE强制返回 XML 类型，再用.value()解包：(SELECT ',' + name FROM sys.tables FOR XML PATH(''), TYPE).value('.', 'NVARCHAR(MAX)') - 漏掉
TYPE，哪怕只有一条含&的记录，整个查询就失败
为什么 STUFF 必须包住整个子查询，不能写在子查询里？
STUFF 的作用是删掉最终拼接字符串开头那个多余的分隔符（比如第一个逗号），它操作对象必须是完整结果字符串，而不是每一行。
- 错误结构：
SELECT STUFF(',' + col, 1, 1, '') FROM t FOR XML PATH('')—— 对每行单独删逗号，毫无意义，还可能语法报错 - 正确结构：
STUFF((SELECT ',' + col FROM t FOR XML PATH(''), TYPE).value('.', 'NVARCHAR(MAX)'), 1, 1, '') - 如果拼接用的是
', ' + col（带空格），STUFF第三个参数就得改成2，否则只删掉逗号、空格剩一个
为什么外层 ORDER BY 对拼接顺序完全无效？
FOR XML PATH 的拼接顺序只取决于子查询内部的执行顺序，而 SQL Server 不保证无序子查询的物理执行顺序——并行计划下，每次运行结果都可能不同。
- 错误假设：以为
SELECT ... FOR XML PATH('') ORDER BY course_id能控制逗号分隔列表顺序 - 必须把
ORDER BY写进子查询里：(SELECT ',' + course_name FROM student_course sc JOIN course c ON sc.course_id = c.course_id WHERE sc.student_id = s.student_id ORDER BY c.course_id FOR XML PATH(''), TYPE) - 即使表上有聚集索引，也不代表子查询会按索引顺序执行；没显式
ORDER BY，结果就是未定义行为
真正容易被忽略的是：这些约束（TYPE、.value()、STUFF 外层包裹、子查询内 ORDER BY）缺一不可，少一个就可能在某个数据分支上静默出错——不是报错，而是结果错位、截断或编码污染。这不是配置问题，是机制使然。
