T-Sol中映射项初始化的低Gas消耗方案及更优实现咨询

基于T-Sol开发智能合约时，需要定期向mapping添加新元素，若元素不存在则需初始化。用到的结构体与mapping定义如下：

struct Person {
  uint age;
  string name;
}

mapping(uint16 => Person) testMapping;

下面对比两种实现方式的Gas消耗，以及是否存在更优初始化方案：

两种方案的Gas效率对比 #

方案1代码 #

testMapping.getAdd(i, Person(0, ""));

T-Sol的getAdd是原子操作：先检查键i对应的元素是否存在，不存在则用传入的默认值初始化并返回，存在则直接返回现有值。整个过程仅做一次存储读取（SLOAD），需初始化时才执行存储写入（SSTORE），无额外分支调用开销。

方案2代码 #

// 注：原代码中`testMapping[18]`应为笔误，改为`testMapping[i]`才符合逻辑
if (!testMapping.exists(i)) {
  testMapping[i] = Person(0, "");
}

该方案需先调用exists做一次存储读取判断元素是否存在，不存在才执行写入。等于多了一次exists方法的调用成本，显式条件分支也会带来少量额外Gas开销——无论元素是否存在，都比方案1多了一次exists调用步骤。

结论 #

不管目标元素存在与否，方案1的Gas消耗都比方案2更优。

更优的初始化方式 #

如果业务场景中，Person的默认值（age=0、name=""）刚好满足初始化需求，其实T-Sol中未初始化的mapping元素本身就会返回结构体的默认值，甚至可以直接使用testMapping[i]，无需显式初始化。但如果业务需要明确区分「从未被初始化」和「初始化为默认值」的状态，可选择：

• 优先使用方案1的getAdd方法：它是T-Sol专为mapping优化的原子操作，代码简洁且省Gas，完全匹配需求。
• 若自行实现判断逻辑，可尝试将exists与赋值合并为单次操作，但本质效率仍不如getAdd。

内容的提问来源于stack exchange，提问作者cryonyx