XSLT 3.0 支持原生 map 数据类型，具备字面量、嵌套、高阶函数、流式构造及 O(1) 查找性能；XSLT 2.0 仅能通过 xsl:key 模拟查表，本质是节点集索引，不支持任意键值、嵌套或函数参数传递，且兼容性受限于处理器版本。
映射能力：XSLT 2.0 没有原生 map，只能靠 xsl:key + xsl:variable 模拟
XSLT 2.0 根本不支持键值对结构（map）或数组（array），所谓“映射”其实是用 xsl:key 定义索引，再配合 xsl:for-each 或 key() 函数查表——本质是 XPath 节点集查找，不是内存级键值访问。
-
xsl:key只能基于 XML 文档节点建立索引，无法存任意类型值（比如字符串→数字、函数→结果） - 模拟“键值变量”需用
- 1
exsl:node-set()（非标准）或递归模板提取，写法冗长且不可变 - 无法嵌套、无法序列化为 JSON、无法传入函数参数——所有操作都绑定在文档上下文里
XSLT 3.0 的 map 是真映射：支持字面量、嵌套、高阶函数和流式构造
XSLT 3.0 把 map 当作一等数据类型，和 xs:string、array 平级，直接参与表达式计算。
- 声明方式简洁：
- 支持动态构造：
map:merge((map{'a':1}, map{'b':2}))，也支持map:for-each($m, function($k, $v) { ... }) - 可作为函数参数/返回值：
... - 与
array互通：array:for-each($arr, function($item) { map{'id': $item/id, 'name': $item/name})
性能差异：大数据量下 map 查找是 O(1)，key() 是 O(log n) 甚至 O(n)
当你要从上千条规则中按 ID 查配置项，XSLT 2.0 的 key('rules', $id) 实际走的是索引扫描（底层仍是节点遍历），而 XSLT 3.0 的 $rules($id) 是哈希查找。
- Saxon-EE 测试显示：10k 条键值对时，
map随机访问比key()快 3–5 倍；若键是动态生成的字符串（如拼接concat($type, '-', $version)），key()甚至要重建索引 - 但注意：
map构建成本略高，频繁构造小映射（如每次循环新建map{'x': $i}）可能反拖慢——应复用或提前构建 -
浏览器环境完全不支持
map（仅 Saxon-PE/EE、Exselt 等引擎支持），别在前端 XSLT 中依赖它
兼容性陷阱：写 XSLT 3.0 映射前必须确认处理器和版本
很多项目声称“支持 XSLT 3.0”，但实际只实现了子集。尤其 Azure Logic Apps 的 Transform XML with Data Mapper 操作，底层用的是 Saxon-HE，不支持 map 和 array（只认 XPath 3.1 函数，不认 XSLT 3.0 数据类型）。
- 先验证：
- 常见断点：Saxon-HE 12.x 支持
map，但 Saxon-HE 10.x 不支持；.NET 的XslCompiledTransform最高只到 XSLT 1.0，硬切 3.0 会直接报错Unsupported XSLT version '3.0' - 如果目标环境锁定 XSLT 2.0（如 BizTalk Server + 默认引擎），老实用
xsl:key+document('')/xsl:stylesheet/xsl:variable模拟静态查表，别强行升级语法
map 不是“语法糖”，它是数据建模范式的切换——一旦你开始用 map:merge 组装配置、用 map:for-each 批量转换、用 $m('key') 替代 key('k', 'v')，就再也回不去 2.0 的节点查表思维了。但这也意味着，每个 map 使用点，都要多问一句：运行时真有这个能力吗？ 
