nodes()必须配合CROSS APPLY使用，因其返回带xml列的虚拟表而非标量值；直接SELECT @xml.nodes()会语法报错，正确写法是FROM @xml.nodes('/path') AS T(c)再对c调用value()或query()。
直接说结论：用 nodes() 拆行、再用 value() 取值，是 SQL Server 里最稳定可靠的 XML 解析路径；跳过 nodes() 直接 value() 或乱套顺序，90% 会返回 NULL 或报错。
为什么 nodes() 必须配合 CROSS APPLY 才能用
nodes() 不是函数，它返回的是一个带 XML 列的虚拟表（行集），SQL Server 不允许你把它当普通表达式写在 SELECT 列表里。常见错误写法：SELECT @xml.nodes('/Items/Item') —— 这会直接报错 “Incorrect syntax near ‘.’”。
- 必须写成
FROM @xml.nodes('/Items/Item') AS T(c)，然后通过CROSS APPLY关联原数据上下文 - 若原始 XML 可能为空或路径不匹配，
CROSS APPLY会丢弃整行；需要保留主表记录时，改用OUTER APPLY - 别名
T(c)中的c是关键：它是每个匹配节点的 XML 实例，后续所有value()和query()都要作用于它
value() 总返回 NULL？检查这四个硬性条件
value() 要求 XPath 精确命中且结果唯一，否则静默返回 NULL（不是报错，所以容易误判成功）。典型失效场景：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 路径大小写不对：
/Root/Item和/root/item是两个不同路径，XML 是严格区分的 - 忘了取文本节点：
'Name'匹配的是<Name>元素节点，但值在内部文本中，得写'(Name/text())[1]' - 属性漏了
@前缀：'id'是子元素，'@id'才是属性值 - 类型强转失败：比如
value('.', 'INT')遇到空字符串或非数字内容，直接 NULL；建议先TRY_CAST(c.value('()[1]', 'NVARCHAR(20)') AS INT)
处理可选字段或嵌套结构时怎么防崩
XML 中字段缺失很常见，但 value() 对空路径不报错却返回 NULL，而类型转换失败会中断整个查询。稳妥做法不是靠运气，而是统一加防御层：
- 所有路径末尾强制加
[1]，例如'(Status/text())[1]'、'(@type)[1]'，避免多节点触发报错 - 非必填字段一律用
ISNULL(..., '')或COALESCE(..., 'N/A')包裹 - 数值/日期类字段，优先用
TRY_CAST(... AS INT)替代直接value(..., 'INT') - 如果某段 XML 结构复杂（比如含多层
<Address><Street><City>），先用query()提取子树再二次nodes()，别一股脑塞进一个value()
最易被忽略的一点：文档节点（document node）是隐式的顶层节点，/Items/Item 这种路径默认从根开始找；但如果 XML 带命名空间（如 <root xmlns="http://abc">），就必须用 WITH XMLNAMESPACES 声明前缀，否则 nodes() 根本找不到任何节点——这点在生产环境出问题时最难排查。
