xsl:fallback用于处理器不支持某扩展指令时的降级处理，而非向后兼容；它仅适用于规范明确允许fallback的可扩展指令，必须作为其直接子元素，且依赖处理器实现。
xsl:fallback 不用于处理向后兼容，而是用来应对 处理器不支持某个扩展指令或特性时的降级处理。
它解决的是“功能不可用”问题，不是版本兼容问题
比如你用了某个 XSLT 2.0 或 3.0 的新指令（如 xsl:try、xsl:evaluate），但运行环境只支持 XSLT 1.0，此时处理器会跳过该指令，转而执行其内部的 xsl:fallback 内容——前提是该指令明确允许 fallback（即规范中定义为“可扩展”且支持 fallback 机制）。
注意：标准 XSLT 指令（如 xsl:for-each、xsl:if）本身不支持 xsl:fallback；只有明确设计为可扩展的指令（如 xsl:sequence 在某些上下文中、或厂商扩展指令）才允许嵌套 xsl:fallback。
典型使用场景
- 在支持扩展函数的处理器中写一个自定义排序指令，同时提供纯 XSLT 1.0 的等效逻辑作为 fallback
- 调用外部 Java/.NET 方法失败时，回退到 XPath 字符串处理
- 使用
xsl:iterate（XSLT 3.0）时，在旧处理器中 fallback 到xsl:for-each+ 递归模板模拟
实际写法要点
-
xsl:fallback必须是父指令的直接子元素，不能单独存在 - 处理器遇到不认识的指令时，仅当该指令在规范中声明“允许 fallback”，才会检查并执行其中的内容
- 不是所有 XSLT 处理器都实现 fallback 机制（尤其老版本 XSLT 1.0 引擎基本不支持）
- 它不改变样式表的 XSLT 版本声明（
version="1.0"还是 "2.0"），只是让代码更具韧性
向后兼容更靠谱的做法
- 明确声明
version属性，并只使用目标环境中确定支持的特性 - 用
xsl:choose+system-property('xsl:version')做版本分支（有限但可行） - 把高版本逻辑封装成独立样式表，通过
xsl:import或参数控制是否启用 - 避免依赖未广泛实现的扩展指令，优先用可移植的 XPath 表达式
基本上就这些。xsl:fallback 是个“安全网”，不是兼容层。真要保版本兼容，靠它远远不够，得从设计源头控制能力边界。
