FOR XML PATH('') 本质是字符串拼接而非XML生成器，不校验标签闭合，也不转义特殊字符如&。
FOR XML PATH('') 本质是字符串拼接，不是XML生成器
它不会校验标签闭合、不转义 & <code>"，直接拼接字段值后返回 varchar 或 nvarchar。你看到的尖括号只是字面字符，SQL Server 不按 XML 规则解析——所以别指望它自动处理特殊字符或生成合规文档。
常见错误现象：SELECT name + ',' FROM sys.tables FOR XML PATH('') 可能报错 XML parsing: line 1, character xx, illegal name character，尤其当表名含 & 或 时。
- 必须用
STUFF(..., 1, 1, '')去首逗号，FOR XML PATH('')本身不提供分隔符控制逻辑 - 若字段值含 XML 敏感字符，必须走
TYPE+.value()路径，否则必崩 - 拼接结果默认无换行、无缩进，纯扁平字符串，别当结构化 XML 用
用 STUFF + FOR XML PATH(''), TYPE 安全拼接带特殊字符的字符串
这是唯一能绕过 XML 解析失败的可靠写法。关键在于先让 SQL Server 内部完成标准转义（& → &， → <code>），再解包成普通字符串。
正确写法示例：
SELECT STUFF((
SELECT ',' + t.name
FROM sys.tables t
FOR XML PATH(''), TYPE
).value('.', 'NVARCHAR(MAX)'), 1, 1, '') AS result-
FOR XML PATH(''), TYPE返回xml数据类型，触发内置转义 -
.value('.', 'NVARCHAR(MAX)')把转义后的 XML 对象安全还原为字符串 - 省略
TYPE就退回原始拼接路径，&会被误认为实体开头，后续字符不匹配直接报错 - ORDER BY 必须写在子查询内，外部排序无效；不加
ORDER BY会导致拼接顺序不确定
GROUP BY 场景下做分组字符串聚合，必须嵌套子查询
不能在主查询里直接对分组字段用 FOR XML PATH，必须把聚合逻辑放在相关子查询中，并显式关联条件。
典型错误写法：SELECT GroupName, FuncationName + ',' FROM #Temp GROUP BY GroupName FOR XML PATH('') ——语法不合法，聚合与 XML 混用会报错。
- 正确结构是：外层
GROUP BY，内层子查询用FOR XML PATH('')拼接本组数据 - 关联条件必须用别名（如
TA.GroupName = TB.GroupName），不能依赖外部作用域 - NULL 值默认被跳过，但若字段本身为
NULL且参与拼接（如FuncationName + ','），结果会变NULL，需提前用ISNULL(FuncationName, '') - 推荐用
STUFF处理首逗号，比LEFT(..., LEN(...) - 1)更稳妥（后者在空结果时会出错）
PATH 参数为空字符串 vs 非空字符串的行为差异
FOR XML PATH('') 和 FOR XML PATH('row') 看似只差个名字，实际语义完全不同。
-
PATH('')：不生成外层节点，只拼接SELECT列表达式的计算结果（如',' + name），最终是单个字符串 -
PATH('row')：每行套一层<row></row>，列按原名或别名生成子元素（如ID→<id>1</id>），结果仍是字符串，但含标签 - 若列别名为
[ColumnName] AS [@attr]（带@），该值会变成父节点属性，而非子元素 - 加
ROOT('rootname')可补最外层根节点，但仅限PATH('')或PATH('row')后追加，不能混用其他模式
真正容易被忽略的是：所有这些输出都是字符串，不是 xml 类型，除非显式加 TYPE。这意味着你不能直接在其上链式调用 .query() 或 .value() ——得先转型。
