合约递归调用限制

递归调用的概念

在 Solidity 中，“递归调用”指的是函数在执行过程中再次调用自己（或通过其他合约的函数再回调到自身）。与常规编程语言类似，递归可能导致栈深度过深、函数重复执行过多等问题。

不过，相比传统编程语言，Solidity 递归有其特殊约束：

波场虚拟机（TVM）的调用栈深度是有限的，每层合约调用都会消耗一定的调用栈深度（默认 64 层的深度上限）。
每次函数调用会消耗额外的 Energy。过度递归调用容易超出交易可用 Energy 上限，从而导致交易失败。
合约中每个函数执行都在同一个执行上下文中完成。如果在递归过程中耗尽了交易的 Energy，就会触发out of energy异常，进而引发回退（revert）。

避免或限制递归

由于 TVM 调用栈和 Energy 都是关键资源，Solidity 社区通常建议在设计智能合约逻辑时避免深层递归。如必须使用递归，开发者需确保：

对递归的深度有清晰的上限设计，防止无限或过深的递归。
对每次调用的 Energy 花费有合理预估，避免因“Energy 不足”而回退整个交易。
关注可替代方案（如循环迭代或其他状态机设计），避免在合约中直接依赖大量递归逻辑。

栈深度限制

TVM 目前限制调用栈深度为 64 层，包括外部合约调用和本合约自身函数再次调用。
若递归过程中超过此栈深度，调用将失败并抛出异常。

在设计合约时，要对可能发生的最深调用路径做评估。大量嵌套调用也可能触发 Stack too deep 编译错误（这是 Solidity 编译器层面的局限），不过该错误多见于局部变量过多、临时变量过多，与函数递归有时并非直接相关，但也提醒开发者在编写复杂函数时要分解逻辑、减少局部变量，或手动进行堆叠管理。

Solidity 错误处理机制

Solidity 中主要有四种错误处理方式：assert、require、revert 和（0.8.4+ 引入的）自定义错误（Custom Errors）。

`assert`

assert 通常用于检查不应该发生的内部错误或严重不变式违反（invariants）。若 assert 失败则会消耗掉所有剩余 Energy 并抛出异常，因此仅用于检测严重错误，或确保永远不会发生的情况。

assert(x == y);

如果断言失败，则表示合约逻辑出现重大缺陷或不一致。
assert 失败会触发编译器在编译时插入的一个 Panic(uint256) 类型错误（Solidity 0.8.0+）。

`require`

require 用于对外部输入和条件进行验证，以确保满足特定先决条件。若 require 判断失败，则会回退（revert）交易，但只会消耗当前已用 Energy。剩余未使用的 Energy 会退还给调用者。

require(msg.sender == owner, "Not the owner");

常见用法包括权限控制、输入合法性验证等。
当 require 失败时，可通过错误消息字符串或自定义错误抛出更具体的信息。

`revert`

revert 关键字可以在函数执行的任意位置直接触发异常回退，能够提供错误原因字符串，或使用自定义错误，方便调试和用户交互。

if (someCondition) {  
    revert("Condition not met");  
}

使用 revert 时通常显示终止函数执行并回退状态。

自定义错误（Custom Errors）

Solidity 0.8.4 及以上版本引入了自定义错误语法。其优势包括：

在 ABI 编码层面更高效，节省 Energy，相比使用字符串通常消耗更少 Energy。
可以在自定义错误中携带参数，让调用者更具体地捕捉错误原因或错误上下文。
自定义错误的声明和使用示例：

// 声明错误  
error Unauthorized(address caller);

contract MyContract {  
    address public owner;
  
		constructor() {
    		owner = msg.sender;
		}

		function doSomething() external {
        if (msg.sender != owner) {
       		 // 使用自定义错误
       		 revert Unauthorized(msg.sender);
   			}
    		// 其他逻辑
		}
}

当 revert Unauthorized(msg.sender) 被触发时，TVM 会回退交易并退还未使用的 Energy。
与 require 的字符串错误信息相比，自定义错误可更灵活、节约空间。

最佳实践与 Energy 考量

分析 Energy 消耗

在 TRON 上，每条交易都会消耗一定数量的 Energy。深层递归或不恰当的错误处理都会导致额外 Energy 消耗。例如：

assert 失败会消耗掉所有剩余 Energy；
require 或 revert 失败只会消耗调用到出错指令为止的 Energy，其余 Energy 会退还；
自定义错误与带字符串信息的 require 和 revert 相比，在编码/解码上更节省 Energy。

因此，在编写合约时要尽量减少不必要的调用深度和失败路径。对业务流程进行周全的检查，尽量在调用开始处检查输入和条件，避免因后续执行的大量运算而浪费 Energy。

使用断言检查核心不变量

对那些在理论上永远不应被破坏的条件使用 assert，出现失败即说明合约存在设计缺陷或逻辑错误。

使用 `require`/`revert` 与自定义错误检查调用者输入与外部条件

require（以及 revert）主要用于验证外部输入或先决条件是否满足，如权限、余额、合约状态等。
结合自定义错误能更高效地传递错误原因。

正确设计函数结构，避免或减少递归

务必在可能出现递归调用的地方做好递归深度限制和对 Energy 的预估。很多情况下可以通过循环或拆分交易来替代深层递归。

关注安全性

递归调用在合约安全上也可能带来重入攻击（Reentrancy），虽然这更多跟外部合约调用和 call 相关。但如果在外部调用中出现意外的回调路径，或在合约中递归调用自身函数修改同一个状态变量，都可能导致状态竞争等安全问题。应结合 ReentrancyGuard 等防护模式，或仔细设计好调用次序与可重入性。