Saxon-PE/EE支持XSLT 2.0+中调用Java静态方法，需显式注册扩展函数并声明命名空间（如xmlns:math="java:java.lang.Math"），而.NET无原生支持，仅能通过XsltArgumentList传入预编译扩展对象。
Java函数在XSLT 2.0+中如何通过Saxon调用
Saxon（尤其是Saxon-PE/EE）支持在XSLT 2.0及以上版本中直接调用Java静态方法，但前提是必须显式注册扩展函数，且XSLT处理器运行在JVM上。原生XSLT 1.0或默认的javax.xml.transform不支持此功能。
常见错误是直接写java:java.lang.Math.random()却未配置Saxon或未声明命名空间，结果报错XTDE1450: Cannot find a matching 1-argument function named {java:java.lang.Math}random()。
- 使用Saxon-HE仍可调用Java类，但仅限public static方法，且类必须在classpath中
- 在XSLT中声明命名空间：
xmlns:math="java:java.lang.Math" - 调用时需注意类型转换：Java的
double会映射为XSLT的xs:double，字符串需用string()显式转 - 避免在
xsl:for-each内高频调用耗时Java方法，Saxon不会自动缓存结果
<xsl:stylesheet version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:math="java:java.lang.Math">
<xsl:template match="/">
<random><xsl:value-of select="math:random()"/></random>
</xsl:template>
</xsl:stylesheet>
.NET函数在XSLT中能否调用？现实限制很明确
目前没有任何主流XSLT处理器（Saxon、Xalan、.NET原生XslCompiledTransform）支持从XSLT中直接调用任意.NET实例或静态方法。.NET平台上的XSLT引擎（如XslCompiledTransform）完全不提供扩展函数注册机制；Saxon .NET版也仅支持有限的内置扩展，不开放用户Java-style的interop。
如果你看到“Saxon.NET支持C#函数”的说法，大概率混淆了Saxon-JS（纯JS实现，不涉.NET）或误读了旧版Saxon-B文档。
立即学习“Java免费学习笔记（深入）”；
-
XslCompiledTransform只允许通过XsltArgumentList传入XsltExtensionObject，但该对象只能暴露符合IXsltExtensionObject接口的方法——即必须预编译为DLL并严格遵循签名约束 - 无法像Java那样用
java:前缀动态调用任意System.DateTime.Now - 更现实的做法是：在C#代码中先执行所需逻辑，把结果作为
XdmValue或参数传入XSLT，而非在模板里调用
替代方案：用外部程序预处理或后处理更可控
当业务逻辑复杂、涉及IO、加密、数据库访问等XSLT不适合的操作时，硬塞进XSLT扩展函数反而增加部署难度和调试成本。推荐分层处理：
- Java侧：用
net.sf.saxon.s9api.Processor加载XSLT前，用registerExtensionFunction()注册自定义ExtensionFunction实现类，比反射调用更安全、可单元测试 - .NET侧：改用
XmlDocument+XPathNavigator在C#中完成计算，再把结果注入XmlDocument节点，最后交给XSLT做纯结构转换 - 跨平台场景：将Java/.NET逻辑封装为HTTP服务（如Spring Boot endpoint或ASP.NET Core Minimal API），XSLT用
saxon:evaluate()配合doc()发起HTTP GET（需Saxon-PE/EE +saxon:allow-uri-read="true"）
安全与兼容性必须前置评估
启用外部函数调用等于打开沙箱缺口。Saxon默认禁用java:调用，需显式设置FeatureKeys.ALLOW_EXTERNAL_FUNCTIONS = true；而生产环境常因策略限制禁止该选项。
- Java类路径污染风险：若XSLT引用了
java.io.File，可能意外触发文件读写——务必用SecurityManager或模块化类加载器隔离 - .NET中
XsltArgumentList.AddExtensionObject()传入的对象，其方法若抛出异常，会以模糊的XsltException向上冒泡，堆栈不包含原始C#行号 - XSLT 3.0的
fn:transform()支持模块化调用，但目前Saxon对Java扩展的支持仍未覆盖全部新特性
真正棘手的不是“怎么写那行java:xxx”，而是谁负责维护那个Java类的版本、日志、线程安全和JVM参数——这些往往在XSLT上线后才暴露。
