理解间接调用：抽象方法与运行时生成
在复杂的typescript项目，尤其是与第三方库交互时，我们可能会遇到一个函数在代码中看似没有直接调用，但运行时却能观察到其执行的情况。这通常发生在以下两种情况：
- 抽象方法的实现与调用： 当一个类（例如NEARFireblocksSigner）继承自一个包含抽象方法的基类或接口（例如near-api-js的Signer类中的signMessage方法），子类必须提供该抽象方法的具体实现。然而，基类或库的内部逻辑可能会在某个深层调用链中触发这个抽象方法，而不是由我们的业务代码直接显式调用。
- 运行时生成的代码： 某些库会根据配置或元数据在运行时动态生成方法。例如，near-api-js中的Contract对象，其方法如deposit_and_stake，并非在编译时就明确存在于代码中，而是在运行时根据智能合约的定义动态创建的。这些动态生成的方法内部会封装对库核心功能的调用。
对于signMessage函数的案例，它正是NEARFireblocksSigner类对near-api-js库中Signer抽象方法的具体实现。因此，要找到其调用方，我们需要深入分析near-api-js库的内部执行流程。
追踪执行流：从业务逻辑到核心签名
要理解signMessage是如何被调用的，我们需要从高层业务逻辑开始，逐步深入到near-api-js库的内部机制。以下是stake函数触发signMessage的完整执行路径：
-
NEARStaker.stake(amount: number) 方法调用： 在NEARStaker类的stake方法中，业务逻辑最终会调用到this.contract.deposit_and_stake。这里的this.contract是一个near-api-js的Contract实例。
async stake(amount: number): Promise<void> { // ... 其他业务逻辑 ... let response = await this.contract.deposit_and_stake({ args: {}, amount: parseNearAmount("" + amount) }); // ... } Contract实例的运行时方法调用：Contract实例上的deposit_and_stake方法是near-api-js在运行时根据合约定义生成的。这些生成的方法内部会统一调用Contract的底层发送交易逻辑。
Contract内部调用 Account.functionCall：near-api-js中所有通过Contract对象进行的合约方法调用（如deposit_and_stake）最终都会通过Account对象的functionCall方法来执行。这是因为Contract的内部实现会委托给其关联的Account实例来处理实际的交易构建和发送。
Account.functionCall 调用 Account.signAndSendTransaction：Account.functionCall方法负责构建函数调用相关的交易操作，并将其封装成一个完整的交易对象，然后调用Account.signAndSendTransaction方法来签名并发送该交易。
Account.signAndSendTransaction 调用 Account.signTransaction：Account.signAndSendTransaction方法的核心职责是获取交易对象，并调用Account.signTransaction方法来完成交易的签名。
Account.signTransaction 调用 transactions 包中的 signTransaction：Account类中的signTransaction方法并非直接执行签名操作，它会进一步委托给near-api-js的transactions包中的一个独立的signTransaction函数。这个函数负责处理交易对象的序列化和签名准备工作。
Scrapfly SDK TypeScript下载使用 Scrapfly SDK（scrapfly-sdk）在 TypeScript 或 JavaScript 中进行网页抓取，用于用户请求抓取 URL、绕过反爬虫防护、渲染页面等场景。
transactions.signTransaction 调用 signTransactionObject：transactions包中的signTransaction函数会调用其内部的signTransactionObject函数。这个函数是实际执行签名操作的逻辑封装。
signTransactionObject 最终调用 Signer.signMessage： 在signTransactionObject函数内部，它会访问传递进来的Signer实例（即NEARFireblocksSigner的实例），并调用其signMessage方法来对交易消息进行实际的加密签名。这就是我们最初寻找的signMessage函数的调用点。
整个调用链可以概括为： stake -> contract.deposit_and_stake (运行时生成) -> Account.functionCall -> Account.signAndSendTransaction -> Account.signTransaction -> transactions.signTransaction -> signTransactionObject -> signer.signMessage。
关于txId的获取与自定义流程
在上述的执行流中，near-api-js库的默认流程并没有在stake方法或其直接调用链中返回txId（交易ID）。库的设计通常是为了简化开发者的交互，自动处理底层的交易签名和发送，而不会将所有中间结果或底层标识符直接暴露给高层业务方法。
如果你的应用确实需要获取txId，你将需要考虑以下两种策略：
- 检查库的返回结果： 仔细查阅near-api-js相关方法的文档，看是否有其他方法或回调函数能提供txId。例如，signAndSendTransaction通常会返回一个包含交易哈希（TxHash，即txId）的FinalExecutionOutcome对象。你可能需要调整你的调用方式，或者在某个中间环节捕获这个返回值。
-
创建自定义签名和发送流程： 如果库的默认流程无法满足需求，你可能需要绕过Contract或Account的高层抽象，自己构建交易、签名并发送。这意味着你需要：
- 手动创建交易对象（Transaction）。
- 使用你的NEARFireblocksSigner实例显式调用signTransactionObject（或类似方法）来获取签名后的交易。
- 手动调用near-api-js提供的RPC客户端方法（如provider.sendTransaction）来发送交易，并从其返回结果中解析txId。
这种自定义流程虽然更复杂，但提供了对交易生命周期更细粒度的控制，从而能够获取到默认流程不提供的中间数据。
总结与最佳实践
追踪抽象方法和第三方库的间接调用是一个常见的挑战，尤其是在调试和理解复杂系统时。以下是一些关键的总结和最佳实践：
- 理解抽象与实现分离： 认识到抽象方法在基类或接口中定义，而其具体实现则在子类中。库通常通过抽象类型来调用这些方法，而非直接调用子类实例。
- 深入阅读库源码： 当框架或库的行为不透明时，最有效的方法是查阅其官方文档，并在必要时深入研究其源代码。GitHub上的代码库通常是最好的信息来源，通过关键词搜索、调用栈分析（如果能复现问题）和逐步调试可以帮助你理解内部机制。
- 利用调试工具： 使用IDE（如VS Code）的调试功能，设置断点并单步执行代码。即使是第三方库的代码，也可以通过源码映射（Source Map）进行调试。观察调用栈（Call Stack）是理解函数调用路径的关键。
- 分析日志和错误信息： 运行时日志有时会提供有用的线索，指示哪个模块或函数正在被执行。
- 考虑自定义扩展： 当库的默认行为无法满足特定需求（如获取特定返回值）时，不要害怕深入其底层API，并根据需要实现自定义的流程。
通过系统性地分析和理解库的内部运作方式，开发者可以更有效地解决这类复杂问题，并更好地掌控应用程序的行为。
