XSLT 1.0 不支持直接调用 Java/.NET 函数，需依赖处理器扩展机制；Saxon 可通过 ExtensionFunctionDefinition 注册 Java 静态方法并调用，.NET 的 XslCompiledTransform 则完全不支持自定义扩展函数，仅限 COM 对象且限制极多；推荐将逻辑移出 XSLT，预处理数据后再用标准 XSLT 转换。
XSLT 1.0 中无法直接调用 Java/.NET 函数
标准 XSLT 1.0 规范不支持任意外部语言函数调用。所谓“调用 Java 方法”，实际依赖于特定 XSLT 处理器的扩展机制，不是跨平台能力。Saxon、Xalan、.NET 的 XslCompiledTransform 各自实现不同，且多数已弃用或严格限制此类功能。
Saxon 9+（Java）中注册 Java 方法需显式绑定
Saxon 支持通过 ExtensionFunctionDefinition 注册 Java 方法，但必须在 Java 侧完成注册，不能在 XSLT 里声明。XSLT 中仅能通过命名空间前缀调用已注册函数，且函数签名需严格匹配。
- Java 类方法必须是
public static，参数和返回类型需映射为 XPath 类型（如XdmValue、String、double） - XSLT 中需声明命名空间，例如：
xmlns:my="http://example.com/myfunctions" - 调用时写法为：
my:formatDate($date, 'yyyy-MM-dd')，前提是该函数已在 Saxon 的Processor实例中注册 - 未注册就调用会报错：
XTDE1425: Cannot find a matching 2-argument function named {http://example.com/myfunctions}formatDate()
Processor processor = new Processor(); Configuration config = processor.getUnderlyingConfiguration(); config.registerExtensionFunction(new MyFormatDateFunction()); // 必须提前注册
.NET 的 XslCompiledTransform 不支持自定义扩展函数
XslCompiledTransform 在 .NET Framework 2.0+ 中**完全移除了对 IXsltContext 和自定义函数的支持**。它只允许通过 XsltArgumentList 传入 XsltArgumentList.AddExtensionObject() 注册 COM 对象（仅限旧版 Windows COM 组件），且要求组件实现 IDispatch，现代 .NET 类（如 public static class Utils）无法使用。
在 Windows 11 上"直接发声"的 TTS（从 WSL2/TUI 调用 powershell.exe + System.Speech）。适用于用户说"说出来/读出来/语音播报/用TTS"，或反馈"没声音/tts 生成的 mp3 是空的/播不出来"，以及需要中文语音但 OpenClaw 内置 tts 不可用时。
- 尝试传入普通 .NET 类会抛出
ArgumentException: Extension object must implement IDispatch - 即使包装为 COM 可行，也仅限 Windows 平台，且需注册类型库、启用 COM 互操作，维护成本极高
- 替代方案是：在 C# 中预处理数据，把结果作为
XdmValue或参数传入 XSLT，而非在 XSLT 中实时调用
更可靠的做法是绕过 XSLT 扩展机制
真正可维护、可测试、跨平台的方案，是把逻辑移出 XSLT：
立即学习“Java免费学习笔记（深入）”；
- 用 Java 或 C# 先解析 XML，调用业务逻辑（如日期格式化、HTTP 请求、数据库查询），生成含结果的新 XML 或 JSON
- 再用纯标准 XSLT 处理该中间结构，避免任何扩展函数依赖
- 若必须动态计算，考虑改用 XSLT 2.0/3.0 的内置函数（如
format-date()、parse-json()），或切换到支持脚本的处理器（如 Saxon-JS 浏览器端运行，但无 Java 调用能力）
硬要绑定语言运行时，等于把 XSLT 变成黑盒胶水层，调试困难、迁移受限、安全策略常拦截——这些细节往往在上线后才暴露。
