深度解析：TypeScript中抽象方法与第三方库的间接调用追踪

问题剖析：间接调用的困惑

在开发过程中，我们有时会遇到这样一种情况：某个函数（例如，在NEAR区块链交互场景中的signMessage）在运行时确实被执行了，其调用日志也清晰可见，但在代码库中却难以直接找到其显式的调用点。例如，在以下stake函数中，尽管我们知道signMessage在交易发送时被调用，但其在stake函数或其内部调用的任何函数中都没有直接体现：

    async stake(amount: number): Promise<void> {
        await this.runSetupIfNeeded();
        typecheck(amount, typeof 1);
        this.log('Validating stake request.');
        let nearWallet = await this.fbks.getVaultAccountAsset("" + this.vaultAccountId, this.assetId);
        let nearInWallet = nearWallet.available;
        if (Number.parseFloat(nearInWallet) < amount) {
            throw new Error(`Vault account ${this.vaultAccountId} has ${nearInWallet} NEAR, but requested to stake ${amount}.`);
        }

        this.log('Validated.');
        this.log('Note - stake,unstake and withdraw will print data including reciepts for transaction, make sure to save it for future reference.', 'WRN');

        (this.config.signer as NEARFireblocksSigner).setNote(`NEAR Staking - Staking ${amount} NEAR`);

        // @ts-ignore - required because deposit_and_stake is generated at runtime.
        let response = await this.contract.deposit_and_stake({
            args: {},
            amount: parseNearAmount("" + amount)
        });

        this.log(`Staked ${amount} NEAR to ${this.contractName}.`);
    }

此外，当我们需要从stake函数返回一个特定的交易ID（txId）时，由于signMessage的间接调用特性，我们可能无法直接从现有流程中获取此值。这种现象通常指向了对第三方库内部机制的理解不足。

核心概念：抽象方法与库内部机制

signMessage之所以难以直接追踪，是因为它是一个抽象方法。在near-api-js库中，Signer类定义了一个抽象的signMessage方法。我们自定义的NEARFireblocksSigner类继承了Signer并提供了signMessage的具体实现。这意味着，signMessage的调用不是由我们直接在业务逻辑代码中显式触发，而是由near-api-js库在执行其核心操作（如发送交易）时，通过多层内部调用间接触发的。

signMessage 函数的调用链路深度解析

为了彻底理解signMessage的调用路径，我们需要深入near-api-js库的内部，追踪从合约方法调用到签名操作的完整流程：

1. 合约实例创建与方法生成： 在NEARStaker的构造函数中，会创建一个Contract实例（来自near-api-js）。这个Contract实例在运行时会动态生成一些方法，例如deposit_and_stake，这些方法被称为changeMethods。
2. deposit_and_stake 方法调用： 在stake()函数中，我们调用了this.contract.deposit_and_stake()。尽管这个方法看起来是我们直接调用的，但它的实际实现位于near-api-js内部。
3. Contract内部实现： near-api-js中所有这些动态生成的合约方法都共享一个通用实现。它们最终都会调用Account对象的functionCall方法。
4. Account.functionCall： functionCall方法负责构建并发送一个函数调用交易。它会进一步调用Account的signAndSendTransaction方法。
5. Account.signAndSendTransaction： 这个方法是发送交易的核心入口。它会调用signTransaction来对交易进行签名。
6. Account.signTransaction： Account的signTransaction方法会委托给@near-api-js/transactions包中的另一个signTransaction实现。
7. @near-api-js/transactions的signTransaction： 这个方法负责实际的交易签名逻辑。它会调用signTransactionObject。
8. signTransactionObject： 最终，signTransactionObject会调用我们自定义的NEARFireblocksSigner类中实现的signMessage抽象方法，完成消息的签名过程。

通过这个调用链路，我们可以清晰地看到，signMessage的调用是深藏于near-api-js库内部的交易处理流程中，而非我们直接在业务代码中调用的。

万物追踪

AI 追踪任何你关心的信息

44

查看详情

关于 txId 返回值的处理

在上述的near-api-js标准交易发送流程中，stake函数及其调用的deposit_and_stake方法，默认情况下并不会直接返回txId（交易ID）。signMessage方法本身主要负责签名操作，其返回值通常是签名后的数据，而不是最终的交易ID。交易ID是在交易被发送到区块链并确认后才生成的。

如果您的应用需要获取txId，您将需要：

1. 检查库的返回值： 仔细查阅near-api-js库中signAndSendTransaction或更高级别方法的返回值。通常，这些方法在成功发送交易后会返回一个包含交易哈希（即txId）的响应对象。
2. 自定义流程： 如果库的现有API不直接提供txId，您可能需要构建自己的交易发送和监听流程。这可能涉及：
   • 手动构造交易。
   • 调用signTransaction获取签名后的交易对象。
   • 调用sendTransaction将交易发送到网络。
   • 解析sendTransaction的响应以获取txId。
   • 或者，监听区块链事件或使用RPC查询来获取交易状态和ID。

总结与建议

理解第三方库的内部工作机制对于调试和扩展应用程序至关重要。当遇到函数调用难以追踪的情况时，请考虑以下几点：

• 抽象方法与接口： 检查相关类是否实现了某个接口或继承了某个抽象类，其核心方法可能由库内部的框架逻辑在特定时机调用。
• 运行时生成代码： 某些库会动态生成代码（如本例中的合约方法），这使得直接的代码搜索变得困难。
• 深入阅读库源码： 最直接有效的方法是查阅第三方库的官方文档和源代码。通过GitHub等平台，您可以追踪方法调用链，理解数据流向。
• 调试工具的局限性： 传统的断点调试可能无法清晰展示所有间接调用，尤其是在涉及异步操作、回调或动态生成代码的场景。此时，日志输出和源码分析变得更为重要。
• 自定义与扩展： 当库的默认行为不满足特定需求（如获取特定返回值）时，不要犹豫去探索自定义实现或扩展库功能的可能性。这通常意味着需要更深入地理解库的底层API。

通过上述分析，希望能帮助您更好地理解和处理TypeScript项目中复杂的第三方库集成场景，尤其是在追踪间接调用和管理特定返回值方面。

以上就是深度解析：TypeScript中抽象方法与第三方库的间接调用追踪的详细内容，更多请关注php中文网其它相关文章！