直接用.nodes()配合CROSS APPLY解析XML是SQL Server存储过程中唯一可靠路径；.nodes()仅生成虚拟行集，必须通过CROSS APPLY挂载才能被引用，且XPath须指向元素节点、区分大小写。
直接用 .nodes() 配合 CROSS APPLY 解析嵌套 XML，是 SQL Server 存储过程中唯一可靠、可维护的路径；别试字符串截取或 CAST 转换，结构一变就全失效。
为什么必须用 CROSS APPLY 而不是直接 SELECT FROM @xml.nodes()
.nodes() 不返回表，只生成一个带 XML 类型列的虚拟行集——它没有物理存储，不能被 FROM 直接引用。漏掉 CROSS APPLY 会报错：Incorrect syntax near '.' 或 Cannot call methods on xml data type。
-
CROSS APPLY把每条匹配节点“挂”到主数据源上，让后续的.value()能访问上下文节点 - 写成
OUTER APPLY可保留原记录（未匹配节点时对应字段为NULL），适合宽松解析场景 - 别名格式必须是
AS T(c)，其中c是上下文节点变量名，T.c.value()才合法；写成T.value()或漏掉括号都会报错
.nodes() 的 XPath 路径必须返回元素节点集合
路径写错是 .value() 总返回 NULL 的最常见原因。XPath 必须指向元素（如 /root/items/item），不能指向文本或属性（如 /root/items/item/name/text() 或 /root/items/item/@id）。
- 正确写法：
@xml.nodes('/root/items/item')→ 每个<item></item>变成一行 - 错误写法：
@xml.nodes('/root/items/item/name')→ 返回文本节点，触发静态错误 - 要取属性值，路径仍写元素，再在
.value()里用@attr：例如T.c.value('(./@id)[1]', 'int') - 路径严格区分大小写，
/Root/Item和/root/item是两个不同路径
多层嵌套怎么一层层拆？用嵌套 CROSS APPLY
XML 有深层结构（比如 <order><items><item><features><feature></feature></features></item></items></order>），不能靠单次 .nodes() 拿到底层字段。
- 第一层：用
CROSS APPLY o.xmlcol.nodes('/order/items/item')拆出 item 行 - 第二层：对每个
item再CROSS APPLY T.c.nodes('features/feature')拆出 feature 行 - 注意第二层的 XPath 是相对路径（从当前
item节点开始），不是从根写起 - 性能敏感时避免三层以上嵌套，深层结构建议提前在应用层扁平化
存储过程里解析 XML 的典型陷阱
在 CREATE PROCEDURE 中传入 XML 参数后，最容易栽在类型隐式转换和空值处理上。
- 参数声明必须是
@xmlData XML，别用VARCHAR(MAX)接收再 CAST——XML 格式不合法时 CAST 会静默失败或抛异常 - 用
.exist()先判断路径是否存在，再调.nodes()，否则无匹配时整行消失（CROSS APPLY行为） -
.value()第二个参数（SQL 类型）必须能容纳实际值，比如用nvarchar(10)提取超长文本会截断，且不报错 - XML 命名空间存在时，
.nodes()必须用WITH XMLNAMESPACES声明前缀，否则路径全不命中
真正难的不是语法，而是理解 .nodes() 的上下文节点机制——它把每个匹配节点变成新行的“根”，后续所有 .value() 和 .query() 都基于这个临时根展开。没想清这层，XPath 就永远写不对。
