Solidity智能合约中Mapping数据的分页实现及最佳实践

问题背景 #

我有一个使用mapping存储数据的Solidity智能合约，希望对该mapping中的数据实现分页功能。当前合约代码如下：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

contract Pagination {
    uint public stringCount;
    mapping (uint => string) public strings;

    function add(string memory item) public {
        stringCount++;
        strings[stringCount]=item;
    }
}

目前考虑两种分页方案：

• 在前端获取mapping中的总数据量，在前端实现分页逻辑，仅加载指定范围的条目；
• 在智能合约内部实现分页逻辑（类似Web2中的做法）。

注：已查阅StackOverflow上的分页相关问题，但均针对数组场景。

方案分析与最佳实践 #

方案1：前端实现分页（推荐） #

这是当前场景下的最优选择，核心逻辑和优势如下：

• 你的mapping使用连续递增的uint作为键（从1到stringCount），前端可以先调用stringCount()获取总数据条数，再根据分页参数（比如每页10条）计算目标页的键范围（例如第2页对应11-20的键），最后逐个调用strings(uint index)接口获取对应数据。
• 优势：合约逻辑无需修改，保持简洁；避免了链上循环带来的高额gas消耗——Solidity中循环的gas成本随次数线性增长，若分页范围过大，极易触发区块gas上限导致操作失败。
• 注意事项：如果后续合约增加删除操作导致键不连续，需要额外维护一个数组记录有效键（删除时移除对应键），否则前端分页会出现空数据。但当前合约只有新增操作，键完全连续，可直接适用。

方案2：合约内部实现分页（不推荐） #

这种方案在当前场景下性价比极低，具体分析：

• 若要在合约内实现分页，需要编写函数遍历指定范围的mapping键，将数据打包为数组返回，示例代码如下：

function getPage(uint pageNum, uint pageSize) public view returns(string[] memory) {
    uint startIndex = (pageNum - 1) * pageSize + 1;
    uint endIndex = startIndex + pageSize - 1;
    if (endIndex > stringCount) {
        endIndex = stringCount;
    }
    uint length = endIndex - startIndex + 1;
    string[] memory pageData = new string[](length);
    for (uint i = startIndex; i <= endIndex; i++) {
        pageData[i - startIndex] = strings[i];
    }
    return pageData;
}

• 劣势：每次调用都会执行链上循环，分页尺寸越大，gas消耗越高，一旦pageSize超出阈值，会直接触发区块gas限制导致调用失败；链上计算和存储成本远高于前端，完全没必要将分页逻辑放在链上。
• 适用场景：仅当mapping的键无连续规律，且无法在前端维护有效键列表时，才考虑在合约内额外维护存储有效键的数组，基于数组实现分页（本质和你查到的数组分页方案一致）。

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