XSLT 1.0 是图灵完备的，因其可通过递归模板和节点集模拟图灵机的状态、纸带与读写头；误解源于无显式循环、变量不可变、XPath 1.0 功能受限及早期处理器性能差等工程性限制。
XSLT 1.0 实际上是图灵完备的，不是图灵不完备的。
为什么常被误认为“不完备”？
这种误解通常源于以下几点：
- 它没有显式的循环语句（如 while 或 for），只能靠
- 变量一旦声明就不能修改（immutable），容易让人觉得“缺乏计算灵活性”；
- XPath 1.0 表达式能力有限（比如不支持高阶函数、无原生分组/聚合、无正则匹配），让某些逻辑写起来冗长甚至需绕路；
- 早期处理器（如 MSXML、xsltproc）对深度递归或大节点集处理效率低，导致实际中“做不了复杂事”的错觉。
XSLT 1.0 确实具备图灵完备性
只要满足两个基本条件：可模拟任意状态转移 + 可无限存储（理论上），就构成图灵完备。XSLT 1.0 满足：
- 通过递归模板 + 参数传递，可实现任意控制流（包括条件跳转、循环展开、模拟栈）；
- 通过节点集、结果树片段（RTF）和 XPath 轴（如 following-sibling、ancestor），可构造并遍历任意复杂的数据结构；
- 已有学术工作证明：仅用 XSLT 1.0 + XPath 1.0 就能模拟图灵机的纸带、状态和读写头（例如用元素嵌套表示纸带，用模板名表示状态，用参数传递当前“头位置”）。
它的真实限制是工程层面的，不是理论层面的
这些限制影响开发体验和性能，但不否定其计算能力：
-
无原生字符串分割/正则：XPath 1.0 没有
replace()或tokenize()，需用递归 substring-after 模拟； - 无内置分组聚合：无法直接按属性值分组求和或计数，必须用 Muenchian 方法（基于 key + generate-id()）；
-
RTF 不能直接作为节点集使用：需用
-
性能敏感操作开销大：如
position() = $n在大节点集中会逐个比对，following-sibling::*遍历整条兄弟链——这属于实现代价，不是能力缺失。
基本上就这些。XSLT 1.0 不是“不能算”，而是“写得费劲、跑得慢、调得头疼”。真正图灵不完备的是像 CSS 选择器或纯正则表达式这类受限系统，而 XSLT 1.0 属于“能算，只是不友好”。
