为何结构相同仅值不同的XML无法在同一XSLT中运行？

哇，卡4小时肯定超闹心的！别慌，既然两份XML的标签/字段完全一致，问题基本都出在值的特殊性或者XSLT里的隐性依赖上，给你列几个最容易踩的坑：

• 值的格式/类型不兼容：比如XSLT里写了针对数字的运算（比如<xsl:value-of select="number(./price)"/>），但新XML里的price值带了逗号、空格，甚至是非打印字符；或者日期格式变了（旧XML是2024-05-20，新XML是5/20/2024），导致转换报错。你可以试试在XSLT里加<xsl:message>输出关键节点的原始值，或者把新XML的可疑值替换成旧XML的有效值，看能不能恢复正常，快速定位问题节点。
• XSLT里的硬编码值依赖：有没有可能你在XSLT里写了类似[.='特定状态']的过滤条件，或者用<xsl:choose>判断了某个固定字符串？新XML里刚好没有这个值，就会导致对应的模板没触发，逻辑走了错误分支。仔细扫一遍XSLT里所有和值相关的判断，有没有硬编码的内容。
• 空白字符的隐形干扰：SQL生成XML时，有时候会给节点值加多余的空格、换行或制表符——比如旧XML是<name>张三</name>，新XML是<name> 张三\n</name>，而XSLT里的匹配是精确匹配，这时候就会失效。可以试试在XPath里用normalize-space(./name)处理后再做判断。
• 命名空间的隐性差异：虽然你说标签一致，但有没有可能新XML悄悄带了命名空间？比如旧XML根节点没有xmlns属性，新XML里加了xmlns="http://your-domain.com"，而XSLT里的XPath没绑定对应命名空间，就会完全匹配不到节点。打开两份XML对比根节点的属性，确认下这点。
• 节点数量的变化：比如旧XML里某个节点是单个的（比如只有一个<order>），新XML里变成了多个；或者反过来，新XML里某个必填节点意外缺失了？虽然你说结构一致，但还是快速核对下节点的数量和层级。

另外给个小技巧：你可以把新XML精简成最小测试用例（比如只保留根节点和几个关键子节点），逐步添加内容，看加到哪个节点时XSLT失效，这样能快速锁定问题点。

内容的提问来源于stack exchange，提问作者Gustavo Jose