local-name-from-QName()用于提取QName值的本地名称部分，它作用于xs:QName类型数据而非节点，适用于处理命名空间前缀的XML元素或属性名，如将ns:elementName解析为elementName；与local-name()不同，后者直接操作节点，而前者操作QName值，常用于XSLT或XQuery中对QName变量的解析、类型转换或序列处理；使用时需确保输入为QName类型，且仅在XPath 2.0及以上版本可用。
local-name-from-QName()函数在XPath中，简单来说，就是用来从一个“合格名称”（Qualified Name，简称QName）中提取出它的“本地名称”部分。换句话说，如果你的XML元素或属性名带有命名空间前缀（比如
ns:elementName），这个函数就能帮你把前面的
ns:去掉，只留下
elementName。它关注的是名称的本质，而非其命名空间前缀的声明方式。
解决方案
这个函数的核心在于处理
xs:QName类型的值。它接受一个QName作为输入，然后返回一个字符串，这个字符串就是该QName的本地名称部分。
想象一下，你正在处理一个复杂的XML文档，里面充斥着各种命名空间。比如，你可能遇到
或者
这样的元素。在很多查询场景下，你可能并不关心它属于哪个命名空间，只想匹配所有名为“Envelope”或“book”的元素。这时候，
local-name-from-QName()就显得尤为重要。
它通常与那些能生成QName值的函数或表达式配合使用。比如，在XSLT或XQuery中，你可能会用
fn:QName()来构造一个QName值，然后用
local-name-from-QName()来分解它。它提供了一种更精细、更类型化的方式来操作名称，而不仅仅是字符串层面的截取。
举个例子，如果你有一个QName值，它在内部可能表示为
{http://www.example.com/ns}book，但其词法表示是ns:book。当你对它应用
local-name-from-QName()时，你将得到
book这个字符串。这与直接操作节点上的
local-name()函数有异曲同工之妙，但应用场景有所不同。
XPath中local-name-from-QName()
与local-name()
函数有何不同？
这可能是最容易让人混淆的地方了。我个人觉得，理解它们之间的核心差异，能让你在XPath的海洋里游刃有余。
local-name()函数，它直接作用于一个节点（无论是元素节点还是属性节点）。你给它一个节点，它就返回这个节点的本地名称。比如说，你有
，你用
local-name(/path/to/my:element)，它就会直接给你
element。这是最常见、最直观的用法，你几乎在所有需要忽略命名空间前缀来匹配元素或属性的场景下都会用到它。
而
local-name-from-QName()呢，它不直接作用于节点。它作用于一个QName值。这个QName值可能是一个变量，一个函数返回的结果，或者通过其他方式构造出来的。它是一个抽象的“名称”概念，而不是文档树上的一个具体位置。
举个例子，假设你在XSLT里定义了一个变量：
let $myQName := fn:QName('http://www.example.com/books', 'bk:Book')
如果你想从$myQName中提取“Book”，你就得用
local-name-from-QName($myQName)。你不能对一个QName值使用
local-name()，因为
$myQName本身不是一个节点。
所以，在我看来，
local-name()更像是你直接在文档树上“指着”某个东西问它的名字，而
local-name-from-QName()则更像是在处理一个“名字的定义”或者“名字的引用”，然后从中提取出它的核心部分。前者是节点操作，后者是数据类型（QName）操作。
什么时候应该优先使用local-name-from-QName()
函数？
说实话，对于日常的XML导航和查询，你大概率会发现
local-name()就已经足够了。但总有些时候，你会突然发现
local-name-from-QName()才是那个你一直在寻找的工具。
我通常会在以下几种场景下考虑它：
-
当你处理的不是直接的XML节点，而是一个QName值的时候。 这可能是通过
fn:QName()
函数动态创建的，或者是从其他函数（比如某些元数据处理函数）返回的QName类型数据。 -
在更高级的XSLT或XQuery编程中。 当你需要进行类型转换、QName的比较、或者将字符串解析为QName并进一步操作其组成部分时，
local-name-from-QName()
就派上用场了。它让你能够以更严格、更类型安全的方式处理名称。 -
处理一系列QName值时。 比如，你有一个序列，里面都是QName，你想把它们全部转换成本地名称的字符串序列。这时候，你就可以用
for $q in $myQNameSequence return local-name-from-QName($q)
。
简而言之，如果你发现你正在操作的不是XML文档中的一个具体元素或属性，而是一个代表“合格名称”的数据类型，那么
local-name-from-QName()就是你的首选。它提供了一种更抽象、更灵活的方式来处理名称的构成。
使用local-name-from-QName()
时可能遇到哪些常见问题或挑战？
即便这个函数看起来直截了当，但在实际使用中，还是会遇到一些小坑，我个人就踩过几次。
一个最常见的问题就是输入类型不匹配。
local-name-from-QName()明确要求它的参数是一个QName类型的值。如果你不小心传入了一个普通的字符串，哪怕这个字符串看起来像一个QName（比如
"ns:myElement"），它也会报错或者返回空。它不会帮你把字符串自动解析成QName。你需要确保你传入的确实是一个
xs:QName类型的数据。如果你的输入是一个字符串，你可能需要先用
fn:QName()之类的函数将其转换为QName类型。
另一个挑战是版本兼容性。
local-name-from-QName()是XPath 2.0及更高版本才有的函数。如果你还在一个XPath 1.0的环境下工作（比如一些老旧的XSLT 1.0处理器），这个函数是不可用的。在这种情况下，你不得不回到字符串操作的老路上，比如使用
substring-after()来手动提取本地名称，但这显然不如
local-name-from-QName()来得优雅和健壮。
还有一点，虽然不是直接的问题，但可能会导致概念上的混淆：它和
local-name()之间的区别。有时候，人们会想当然地认为它们可以互换使用。但正如前面提到的，它们操作的对象是不同的。理解这个根本区别，才能避免在调试时抓耳挠腮。
最后，虽然不是性能瓶颈，但在某些极端复杂的场景下，涉及QName的类型转换和处理，可能会带来微小的性能开销。但这通常不是我们日常开发中需要过度担忧的问题。关键还是在于正确理解和使用它的语义。
