Solidity动态数组全攻略：从零到精通，带你窥探EVM底层！

天涯学馆
发布于 6小时前
阅读 33

Solidity的动态数组，乍一看就是个能伸能缩的列表，简单得不行，但你真以为它就这么好搞定？别天真！这玩意儿在以太坊虚拟机（EVM）里藏着无数玄机，从存储布局到gas消耗，从数组操作到字节码细节，稍不留神就可能写出个天价gas的合约！动态数组它到底是个啥？动态数组，简单说，就是个长度可变的数组

Solidity的动态数组，乍一看就是个能伸能缩的列表，简单得不行，但你真以为它就这么好搞定？别天真！这玩意儿在以太坊虚拟机（EVM）里藏着无数玄机，从存储布局到gas消耗，从数组操作到字节码细节，稍不留神就可能写出个天价gas的合约！

## 动态数组它到底是个啥？

动态数组，简单说，就是个长度可变的数组。Solidity里，你写个`uint[]`或者`address[]`，这就是动态数组，跟固定大小的`uint[10]`完全不是一回事。动态数组能随时`push`新元素，`pop`掉最后一个，还能随便读写索引，灵活得一批。但这灵活背后，EVM的存储机制、gas计算、内存管理可复杂得要命。咱得从最基础的声明和操作讲起，逐步深入到EVM的存储槽、字节码，甚至gas的底层逻辑。

动态数组主要出现在两个地方：`storage`（区块链上的持久化存储）和`memory`（函数运行时的临时内存）。`storage`的动态数组数据存在链上，贵得离谱；`memory`的动态数组只在函数执行时存在，省gas但不持久。两者用法和实现差别巨大，咱得一个一个拆开讲。

## 动态数组的基本操作

先来点直观的代码，感受下动态数组的用法。假设你想搞个合约，存一堆用户的ID，代码大概是这模样：

```solidity
pragma solidity ^0.8.0;

contract ArrayPlayground {
    uint[] public userIds;

function addId(uint _id) public {
        userIds.push(_id);
    }

function getId(uint index) public view returns (uint) {
        return userIds[index];
    }

function removeLastId() public {
        userIds.pop();
    }

function getArrayLength() public view returns (uint) {
        return userIds.length;
    }
}
```

这代码简单得像喝水：`uint[]`声明了个动态数组，`push`加元素，`pop`删最后一个，`length`查长度，`[]`读指定索引。跑起来没毛病，但这只是表面的皮。动态数组的真正复杂性在EVM的存储机制里，咱得深入底层，看看这些操作在区块链上咋实现的。

## 动态数组咋存的？

Solidity跑在EVM上，EVM的存储是个键值对数据库，键和值都是256位。动态数组既然能变长，数据咋存？咋扩容？为啥`push`和`pop`的gas费差这么多？咱从EVM的存储槽开始讲。

### 存储槽的布局

在`storage`里，动态数组分两部分存储：**长度**和**数据**。比如上面代码的`userIds`，Solidity给它分配一个存储槽，假设是槽0。这个槽只存数组的**长度**（uint256格式）。实际的数组元素存在哪？它们被存在一堆基于槽0哈希计算出来的位置。

EVM用Keccak-256哈希算法来确定元素的位置，公式是：

```
keccak256(slot) + index
```

- `slot`是数组的基槽（比如0）。
- `index`是元素的索引（从0开始）。
- `keccak256(slot)`生成一个256位哈希值，作为数组数据的起始地址。
- 每个元素占一个存储槽（256位），`uint`正好是256位，所以一个`uint`元素占一个槽。

举个例子，`userIds`在槽0，长度是4，元素是`[100, 200, 300, 400]`，存储布局是：

- 槽0：存长度`4`。
- 槽`keccak256(0) + 0`：存`100`。
- 槽`keccak256(0) + 1`：存`200`。
- 槽`keccak256(0) + 2`：存`300`。
- 槽`keccak256(0) + 3`：存`400`。

为啥用`keccak256`？因为EVM的存储是稀疏的，`keccak256`能保证不同数组的存储位置不冲突，相当于给每个动态数组分配了个“独立地址空间”。

### push操作的底层

调用`userIds.push(500)`，EVM干了啥？

1. **读长度**：用`SLOAD`从槽0读当前长度（比如4），gas费2100。
2. **更新长度**：把槽0的长度加1（变成5），用`SSTORE`写入，gas费20000（首次写入）或5000（更新）。
3. **写新元素**：计算新元素的位置`keccak256(0) + 4`，用`SSTORE`写入`500`，又花20000或5000 gas。
4. **溢出检查**：Solidity 0.8.0+会检查长度是否超过`2^256-1`（几乎不可能）。

`push`至少两次`SSTORE`，gas费不低，尤其是数组刚初始化时，槽都是空的，写入成本更高。

### pop操作的细节

`userIds.pop()`又咋回事？流程是：

1. **读长度**：`SLOAD`从槽0读长度（比如5），gas费2100。
2. **检查非空**：如果长度是0，抛出错误（Solidity 0.8.0+自动检查）。
3. **清空最后一个元素**：计算最后一个元素的位置`keccak256(0) + 4`，用`SSTORE`清零，gas费5000，但可能触发15000 gas的退款。
4. **减少长度**：用`SSTORE`把槽0的长度减1，gas费5000。

`pop`也涉及两次`SSTORE`，但清零操作有退款，所以gas费通常比`push`低。

### 读元素的逻辑

`userIds[2]`咋读？EVM会：

1. 计算槽：`keccak256(0) + 2`。
2. 用`SLOAD`读取这个槽，gas费2100。

读取简单，但如果索引越界（比如`userIds[999]`而数组只有4个元素），Solidity会抛出错误，浪费gas。

## 内存中的动态数组：完全不同的世界

`memory`里的动态数组跟`storage`大不一样。`memory`是临时的，数据在函数执行完就没了，gas费也低得多。来看个例子：

```solidity
function createTempArray(uint size) public pure returns (uint[] memory) {
    uint[] memory tempArray = new uint[](size);
    tempArray[0] = 42;
    tempArray.push(100);
    return tempArray;
}
```

`memory`数组的存储是连续的，类似C语言的数组。EVM在内存里分配一块空间，结构是：

- 前32字节：存数组长度。
- 接下来N个32字节：存N个元素。

`push`操作会重新分配内存，把原数组内容拷贝到新内存，再加新元素。拷贝操作耗时，数组越大，gas费越高。所以`memory`数组适合小规模操作，`storage`数组适合持久化数据。

## 动态数组的复杂玩法

基础操作讲完了，咱来看点高阶的。动态数组在实际合约里常跟其他逻辑配合，比如删除中间元素、批量操作、或者跟映射（mapping）组合。

### 删除中间元素

Solidity的动态数组不能直接删中间元素（`delete userIds[2]`只会把元素置0，不改长度）。咋办？常用“移位法”：

```solidity
function removeIdAt(uint index) public {
    require(index < userIds.length, "Index out of bounds");
    for (uint i = index; i < userIds.length - 1; i++) {
        userIds[i] = userIds[i + 1];
    }
    userIds.pop();
}
```

这代码把`index`后面的元素往前挪，最后`pop`掉多余的。问题在哪？每次移位都要`SSTORE`，数组越大，gas费越恐怖。如果数组有1000个元素，删第0个，得挪999次，gas费能让你破产。

替代方案是用“标记法”：不真删元素，只标记为无效。比如用0表示删除，或者用映射记录有效性：

```solidity
mapping(uint => bool) public isValid;

function markInvalid(uint index) public {
    require(index < userIds.length, "Index out of bounds");
    isValid[index] = false;
}
```

这方法gas费低，但读取时得检查`isValid`，逻辑复杂点。

### 批量操作

批量添加元素咋整？循环`push`可以，但gas费高。更好的办法是用`memory`数组预处理：

```solidity
function batchAddIds(uint[] memory newIds) public {
    for (uint i = 0; i < newIds.length; i++) {
        userIds.push(newIds[i]);
    }
}
```

这代码在`memory`里准备数据，再逐个`push`到`storage`。如果`newIds`很大，gas费还是高。Solidity 0.8.0+支持直接赋值：

```solidity
function setIds(uint[] memory newIds) public {
    userIds = newIds;
}
```

这会覆盖整个数组，效率高，但清空原数据。如果想追加，还得用`push`。

### 跟映射结合

动态数组和映射是绝配。比如，存每个用户的订单ID：

```solidity
mapping(address => uint[]) public userOrders;

function addOrder(address user, uint orderId) public {
    userOrders[user].push(orderId);
}
```

每个`user`有自己的动态数组，存储槽基于`keccak256(user, slot)`。这让数据组织灵活，但gas费也高。

## 动态数组的EVM指令

想更硬核？咱来看`push`的字节码。假设`push(42)`，Solidity编译器生成类似这样的EVM指令：

```
SLOAD 0x0           // 读长度
DUP1                // 复制长度
SHA3                // 计算keccak256(0)
ADD                 // 加上索引
PUSH1 0x2a          // 推入42
SSTORE              // 存数据
PUSH1 0x1           // 推入1
ADD                 // 长度+1
SSTORE 0x0          // 更新长度
```

`SHA3`和`SSTORE`是gas大户。想省gas？尽量减少`SSTORE`，或者用`memory`预计算。

## 投票系统合约

来个实战：用动态数组实现投票系统。需求是用户投票给候选人，记录票数和投票者：

```solidity
pragma solidity ^0.8.0;

contract VotingSystem {
    struct Candidate {
        string name;
        uint voteCount;
        address[] voters;
    }

Candidate[] public candidates;

function addCandidate(string memory _name) public {
        candidates.push(Candidate(_name, 0, new address[](0)));
    }

function vote(uint candidateIndex) public {
        require(candidateIndex < candidates.length, "Invalid candidate");
        require(!hasVoted(candidateIndex, msg.sender), "Already voted");
        candidates[candidateIndex].voteCount++;
        candidates[candidateIndex].voters.push(msg.sender);
    }

function hasVoted(uint candidateIndex, address voter) public view returns (bool) {
        address[] memory voters = candidates[candidateIndex].voters;
        for (uint i = 0; i < voters.length; i++) {
            if (voters[i] == voter) return true;
        }
        return false;
    }
}
```

这代码用动态数组`candidates`存候选人，每个候选人有`voters`动态数组。`hasVoted`的循环可能很耗gas，优化方案是用映射：

```solidity
mapping(uint => mapping(address => bool)) public hasVotedMap;

function voteWithMap(uint candidateIndex) public {
    require(candidateIndex < candidates.length, "Invalid candidate");
    require(!hasVotedMap[candidateIndex][msg.sender], "Already voted");
    hasVotedMap[candidateIndex][msg.sender] = true;
    candidates[candidateIndex].voteCount++;
    candidates[candidateIndex].voters.push(msg.sender);
}
```

映射查找是O(1)，效率更高。

## 多维动态数组

动态数组还能玩多维，比如：

```solidity
uint[][] public matrix;

function addRow(uint[] memory row) public {
    matrix.push(row);
}
```

多维数组的槽是`keccak256(keccak256(slot) + i) + j`，gas费更高，慎用。

## gas和存储的博弈

动态数组的gas费主要来自`SSTORE`（5000-20000 gas）和`SLOAD`（2100 gas）。`push`和`pop`都涉及多次存储操作，数组越大，成本越高。`memory`操作便宜，但不持久。想写高效合约，得多理解EVM的存储模型和字节码。

## 动态数组的局限

动态数组灵活，但有坑：

- **gas费高**：`SSTORE`是大头，循环操作更贵。
- **遍历慢**：大数组遍历可能耗光gas。
- **存储复杂**：`keccak256`计算位置增加开销。

替代方案？映射、固定数组、或OpenZeppelin的数组库，都能省点gas。

## EVM的存储优化

EVM的存储是稀疏的，每个槽256位，`uint`正好填满，但`uint8`也会占一个槽，浪费空间。想省空间？可以打包数据：

```solidity
struct Packed {
    uint128 a;
    uint128 b;
}

Packed[] public packedArray;
```

这把两个`uint128`塞一个槽，省一半存储。但读取时得小心字节对齐。

## 动态数组的复杂应用

再来个复杂点的例子：实现一个动态NFT市场，记录每个NFT的出价历史：

```solidity
pragma solidity ^0.8.0;

contract NFTMarket {
    struct Bid {
        address bidder;
        uint amount;
    }

struct NFT {
        uint id;
        Bid[] bids;
    }

NFT[] public nfts;

function listNFT(uint id) public {
        nfts.push(NFT(id, new Bid[](0)));
    }

function placeBid(uint nftIndex, uint amount) public {
        require(nftIndex < nfts.length, "Invalid NFT");
        nfts[nftIndex].bids.push(Bid(msg.sender, amount));
    }

function getBids(uint nftIndex) public view returns (Bid[] memory) {
        return nfts[nftIndex].bids;
    }
}
```

这代码用动态数组`bids`存每个NFT的出价历史。注意，`getBids`返回整个数组，可能很耗gas，适合小规模数据。

## 动态数组的调用栈

`push`的字节码只是冰山一角。实际合约里，Solidity还会插入溢出检查、边界检查等逻辑，增加字节码复杂性。比如`userIds[2]`的读取，字节码可能是：

```
PUSH1 0x2           // 索引2
SLOAD 0x0           // 读长度
LT                  // 检查索引<长度
JUMPI               // 如果越界，抛错
SHA3                // 计算keccak256(0)
ADD                 // 加上索引
SLOAD               // 读数据
```

每步都有gas成本，边界检查还可能触发`REVERT`，浪费gas。

## 动态数组的边界情况

动态数组还有啥冷门知识？比如空数组的处理：

```solidity
uint[] public emptyArray;

function initEmpty() public {
    emptyArray = new uint[](0);
}
```

空数组的长度是0，槽0存0，但`push`照样能用，因为EVM会动态分配新槽。另一个冷门点是`delete`：

```solidity
function clearArray() public {
    delete userIds;
}
```

`delete userIds`会把长度槽清零，但不清理数据槽（只是标记为0），gas费较低。

## 动态数组的排序

动态数组还能干啥？比如实现链上排序（虽然gas费高，慎用）：

```solidity
function sortIds() public {
    for (uint i = 0; i < userIds.length; i++) {
        for (uint j = i + 1; j < userIds.length; j++) {
            if (userIds[i] > userIds[j]) {
                (userIds[i], userIds[j]) = (userIds[j], userIds[i]);
            }
        }
    }
}
```

这冒泡排序每次交换都要两次`SSTORE`，gas费爆炸。实际开发中，尽量把排序放到链下。

EVM的存储限制决定了动态数组的玩法。每个槽256位，最大长度`2^256-1`，但gas费和区块gas限制让你用不了那么大。实际中，数组超几千个元素，操作就慢得像乌龟了。

每次`SSTORE`都会改EVM的状态树（Patricia Merkle Trie），增加区块的存储开销。动态数组的频繁操作会让状态树膨胀，影响节点同步。所以，大规模数组操作得谨慎。

## 动态数组的多维复杂应用

多维动态数组咋玩？比如一个二维数组存用户评分：

```solidity
uint[][] public ratings;

function addRating(uint userId, uint score) public {
    while (ratings.length <= userId) {
        ratings.push(new uint[](0));
    }
    ratings[userId].push(score);
}
```

这代码动态扩展二维数组，存储槽计算复杂，gas费高得离谱，实际中尽量用映射代替。

## EVM的内存管理

`memory`数组的分配在EVM的内存区域，起始地址从0x80开始，动态增长。`new uint[](n)`会分配`32 + n*32`字节，拷贝操作由`MSTORE`和`MCOPY`指令完成。`memory`操作的gas费跟数组大小线性相关，远比`storage`便宜。

## 动态数组的冷门坑

还有啥坑？比如`storage`数组的引用问题：

```solidity
function badPractice() public {
    uint[] storage ref = userIds;
    ref.push(999);
}
```

`ref`是`storage`引用，直接改`userIds`。但如果不小心用`memory`引用，会拷贝数据，改动不影响`storage`，容易出bug。

## 动态数组的复杂数据结构

最后来个大招：用动态数组实现一个简单的链上数据库，存用户和他们的交易记录：

```solidity
pragma solidity ^0.8.0;

contract UserDatabase {
    struct Transaction {
        uint amount;
        uint timestamp;
    }

struct User {
        address userAddress;
        Transaction[] transactions;
    }

User[] public users;

function addUser(address _userAddress) public {
        users.push(User(_userAddress, new Transaction[](0)));
    }

function addTransaction(uint userIndex, uint amount) public {
        require(userIndex < users.length, "Invalid user");
        users[userIndex].transactions.push(Transaction(amount, block.timestamp));
    }

function getUserTransactions(uint userIndex) public view returns (Transaction[] memory) {
        return users[userIndex].transactions;
    }
}
```

这代码用动态数组嵌套，存用户和交易历史。`getUserTransactions`返回整个数组，gas费高，适合小数据量。

## 字节码的终极分析

再看个`pop`的字节码：

```
SLOAD 0x0           // 读长度
DUP1                // 复制长度
PUSH1 0x0           // 推入0
EQ                  // 检查长度==0
JUMPI               // 如果0，抛错
SUB                 // 长度-1
DUP1                // 复制新长度
SHA3                // 计算最后一个元素位置
ADD                 // 加上索引
PUSH1 0x0           // 推入0
SSTORE              // 清零
SSTORE 0x0          // 更新长度
```

每步都在烧gas，`SHA3`和`SSTORE`是主力。想省gas？尽量批量操作，少用循环。

动态数组它到底是个啥？

动态数组，简单说，就是个长度可变的数组。Solidity里，你写个uint[]或者address[]，这就是动态数组，跟固定大小的uint[10]完全不是一回事。动态数组能随时push新元素，pop掉最后一个，还能随便读写索引，灵活得一批。但这灵活背后，EVM的存储机制、gas计算、内存管理可复杂得要命。咱得从最基础的声明和操作讲起，逐步深入到EVM的存储槽、字节码，甚至gas的底层逻辑。

动态数组主要出现在两个地方：storage（区块链上的持久化存储）和memory（函数运行时的临时内存）。storage的动态数组数据存在链上，贵得离谱；memory的动态数组只在函数执行时存在，省gas但不持久。两者用法和实现差别巨大，咱得一个一个拆开讲。

动态数组的基本操作

先来点直观的代码，感受下动态数组的用法。假设你想搞个合约，存一堆用户的ID，代码大概是这模样：

pragma solidity ^0.8.0;

contract ArrayPlayground {
    uint[] public userIds;

    function addId(uint _id) public {
        userIds.push(_id);
    }

    function getId(uint index) public view returns (uint) {
        return userIds[index];
    }

    function removeLastId() public {
        userIds.pop();
    }

    function getArrayLength() public view returns (uint) {
        return userIds.length;
    }
}

这代码简单得像喝水：uint[]声明了个动态数组，push加元素，pop删最后一个，length查长度，[]读指定索引。跑起来没毛病，但这只是表面的皮。动态数组的真正复杂性在EVM的存储机制里，咱得深入底层，看看这些操作在区块链上咋实现的。

动态数组咋存的？

Solidity跑在EVM上，EVM的存储是个键值对数据库，键和值都是256位。动态数组既然能变长，数据咋存？咋扩容？为啥push和pop的gas费差这么多？咱从EVM的存储槽开始讲。

存储槽的布局

在storage里，动态数组分两部分存储：长度和数据。比如上面代码的userIds，Solidity给它分配一个存储槽，假设是槽0。这个槽只存数组的长度（uint256格式）。实际的数组元素存在哪？它们被存在一堆基于槽0哈希计算出来的位置。

EVM用Keccak-256哈希算法来确定元素的位置，公式是：

keccak256(slot) + index

slot是数组的基槽（比如0）。
index是元素的索引（从0开始）。
keccak256(slot)生成一个256位哈希值，作为数组数据的起始地址。
每个元素占一个存储槽（256位），uint正好是256位，所以一个uint元素占一个槽。

举个例子，userIds在槽0，长度是4，元素是[100, 200, 300, 400]，存储布局是：

槽0：存长度4。
槽keccak256(0) + 0：存100。
槽keccak256(0) + 1：存200。
槽keccak256(0) + 2：存300。
槽keccak256(0) + 3：存400。

为啥用keccak256？因为EVM的存储是稀疏的，keccak256能保证不同数组的存储位置不冲突，相当于给每个动态数组分配了个“独立地址空间”。

push操作的底层

调用userIds.push(500)，EVM干了啥？

读长度：用SLOAD从槽0读当前长度（比如4），gas费2100。
更新长度：把槽0的长度加1（变成5），用SSTORE写入，gas费20000（首次写入）或5000（更新）。
写新元素：计算新元素的位置keccak256(0) + 4，用SSTORE写入500，又花20000或5000 gas。
溢出检查：Solidity 0.8.0+会检查长度是否超过2^256-1（几乎不可能）。

push至少两次SSTORE，gas费不低，尤其是数组刚初始化时，槽都是空的，写入成本更高。

pop操作的细节

userIds.pop()又咋回事？流程是：

读长度：SLOAD从槽0读长度（比如5），gas费2100。
检查非空：如果长度是0，抛出错误（Solidity 0.8.0+自动检查）。
清空最后一个元素：计算最后一个元素的位置keccak256(0) + 4，用SSTORE清零，gas费5000，但可能触发15000 gas的退款。
减少长度：用SSTORE把槽0的长度减1，gas费5000。

pop也涉及两次SSTORE，但清零操作有退款，所以gas费通常比push低。

读元素的逻辑

userIds[2]咋读？EVM会：

计算槽：keccak256(0) + 2。
用SLOAD读取这个槽，gas费2100。

读取简单，但如果索引越界（比如userIds[999]而数组只有4个元素），Solidity会抛出错误，浪费gas。

内存中的动态数组：完全不同的世界

memory里的动态数组跟storage大不一样。memory是临时的，数据在函数执行完就没了，gas费也低得多。来看个例子：

function createTempArray(uint size) public pure returns (uint[] memory) {
    uint[] memory tempArray = new uint[](size);
    tempArray[0] = 42;
    tempArray.push(100);
    return tempArray;
}

memory数组的存储是连续的，类似C语言的数组。EVM在内存里分配一块空间，结构是：

前32字节：存数组长度。
接下来N个32字节：存N个元素。

push操作会重新分配内存，把原数组内容拷贝到新内存，再加新元素。拷贝操作耗时，数组越大，gas费越高。所以memory数组适合小规模操作，storage数组适合持久化数据。

动态数组的复杂玩法

基础操作讲完了，咱来看点高阶的。动态数组在实际合约里常跟其他逻辑配合，比如删除中间元素、批量操作、或者跟映射（mapping）组合。

删除中间元素

Solidity的动态数组不能直接删中间元素（delete userIds[2]只会把元素置0，不改长度）。咋办？常用“移位法”：

function removeIdAt(uint index) public {
    require(index &lt; userIds.length, "Index out of bounds");
    for (uint i = index; i &lt; userIds.length - 1; i++) {
        userIds[i] = userIds[i + 1];
    }
    userIds.pop();
}

这代码把index后面的元素往前挪，最后pop掉多余的。问题在哪？每次移位都要SSTORE，数组越大，gas费越恐怖。如果数组有1000个元素，删第0个，得挪999次，gas费能让你破产。

替代方案是用“标记法”：不真删元素，只标记为无效。比如用0表示删除，或者用映射记录有效性：

mapping(uint => bool) public isValid;

function markInvalid(uint index) public {
    require(index &lt; userIds.length, "Index out of bounds");
    isValid[index] = false;
}

这方法gas费低，但读取时得检查isValid，逻辑复杂点。

批量操作

批量添加元素咋整？循环push可以，但gas费高。更好的办法是用memory数组预处理：

function batchAddIds(uint[] memory newIds) public {
    for (uint i = 0; i &lt; newIds.length; i++) {
        userIds.push(newIds[i]);
    }
}

这代码在memory里准备数据，再逐个push到storage。如果newIds很大，gas费还是高。Solidity 0.8.0+支持直接赋值：

function setIds(uint[] memory newIds) public {
    userIds = newIds;
}

这会覆盖整个数组，效率高，但清空原数据。如果想追加，还得用push。

跟映射结合

动态数组和映射是绝配。比如，存每个用户的订单ID：

mapping(address => uint[]) public userOrders;

function addOrder(address user, uint orderId) public {
    userOrders[user].push(orderId);
}

每个user有自己的动态数组，存储槽基于keccak256(user, slot)。这让数据组织灵活，但gas费也高。

动态数组的EVM指令

想更硬核？咱来看push的字节码。假设push(42)，Solidity编译器生成类似这样的EVM指令：

SLOAD 0x0           // 读长度
DUP1                // 复制长度
SHA3                // 计算keccak256(0)
ADD                 // 加上索引
PUSH1 0x2a          // 推入42
SSTORE              // 存数据
PUSH1 0x1           // 推入1
ADD                 // 长度+1
SSTORE 0x0          // 更新长度

SHA3和SSTORE是gas大户。想省gas？尽量减少SSTORE，或者用memory预计算。

投票系统合约

来个实战：用动态数组实现投票系统。需求是用户投票给候选人，记录票数和投票者：

pragma solidity ^0.8.0;

contract VotingSystem {
    struct Candidate {
        string name;
        uint voteCount;
        address[] voters;
    }

    Candidate[] public candidates;

    function addCandidate(string memory _name) public {
        candidates.push(Candidate(_name, 0, new address[](0)));
    }

    function vote(uint candidateIndex) public {
        require(candidateIndex &lt; candidates.length, "Invalid candidate");
        require(!hasVoted(candidateIndex, msg.sender), "Already voted");
        candidates[candidateIndex].voteCount++;
        candidates[candidateIndex].voters.push(msg.sender);
    }

    function hasVoted(uint candidateIndex, address voter) public view returns (bool) {
        address[] memory voters = candidates[candidateIndex].voters;
        for (uint i = 0; i &lt; voters.length; i++) {
            if (voters[i] == voter) return true;
        }
        return false;
    }
}

这代码用动态数组candidates存候选人，每个候选人有voters动态数组。hasVoted的循环可能很耗gas，优化方案是用映射：

mapping(uint => mapping(address => bool)) public hasVotedMap;

function voteWithMap(uint candidateIndex) public {
    require(candidateIndex &lt; candidates.length, "Invalid candidate");
    require(!hasVotedMap[candidateIndex][msg.sender], "Already voted");
    hasVotedMap[candidateIndex][msg.sender] = true;
    candidates[candidateIndex].voteCount++;
    candidates[candidateIndex].voters.push(msg.sender);
}

映射查找是O(1)，效率更高。

多维动态数组

动态数组还能玩多维，比如：

uint[][] public matrix;

function addRow(uint[] memory row) public {
    matrix.push(row);
}

多维数组的槽是keccak256(keccak256(slot) + i) + j，gas费更高，慎用。

gas和存储的博弈

动态数组的gas费主要来自SSTORE（5000-20000 gas）和SLOAD（2100 gas）。push和pop都涉及多次存储操作，数组越大，成本越高。memory操作便宜，但不持久。想写高效合约，得多理解EVM的存储模型和字节码。

动态数组的局限

动态数组灵活，但有坑：

gas费高：SSTORE是大头，循环操作更贵。
遍历慢：大数组遍历可能耗光gas。
存储复杂：keccak256计算位置增加开销。

替代方案？映射、固定数组、或OpenZeppelin的数组库，都能省点gas。

EVM的存储优化

EVM的存储是稀疏的，每个槽256位，uint正好填满，但uint8也会占一个槽，浪费空间。想省空间？可以打包数据：

struct Packed {
    uint128 a;
    uint128 b;
}

Packed[] public packedArray;

这把两个uint128塞一个槽，省一半存储。但读取时得小心字节对齐。

动态数组的复杂应用

再来个复杂点的例子：实现一个动态NFT市场，记录每个NFT的出价历史：

pragma solidity ^0.8.0;

contract NFTMarket {
    struct Bid {
        address bidder;
        uint amount;
    }

    struct NFT {
        uint id;
        Bid[] bids;
    }

    NFT[] public nfts;

    function listNFT(uint id) public {
        nfts.push(NFT(id, new Bid[](0)));
    }

    function placeBid(uint nftIndex, uint amount) public {
        require(nftIndex &lt; nfts.length, "Invalid NFT");
        nfts[nftIndex].bids.push(Bid(msg.sender, amount));
    }

    function getBids(uint nftIndex) public view returns (Bid[] memory) {
        return nfts[nftIndex].bids;
    }
}

这代码用动态数组bids存每个NFT的出价历史。注意，getBids返回整个数组，可能很耗gas，适合小规模数据。

动态数组的调用栈

push的字节码只是冰山一角。实际合约里，Solidity还会插入溢出检查、边界检查等逻辑，增加字节码复杂性。比如userIds[2]的读取，字节码可能是：

PUSH1 0x2           // 索引2
SLOAD 0x0           // 读长度
LT                  // 检查索引&lt;长度
JUMPI               // 如果越界，抛错
SHA3                // 计算keccak256(0)
ADD                 // 加上索引
SLOAD               // 读数据

每步都有gas成本，边界检查还可能触发REVERT，浪费gas。

动态数组的边界情况

动态数组还有啥冷门知识？比如空数组的处理：

uint[] public emptyArray;

function initEmpty() public {
    emptyArray = new uint[](0);
}

空数组的长度是0，槽0存0，但push照样能用，因为EVM会动态分配新槽。另一个冷门点是delete：

function clearArray() public {
    delete userIds;
}

delete userIds会把长度槽清零，但不清理数据槽（只是标记为0），gas费较低。

动态数组的排序

动态数组还能干啥？比如实现链上排序（虽然gas费高，慎用）：

function sortIds() public {
    for (uint i = 0; i &lt; userIds.length; i++) {
        for (uint j = i + 1; j &lt; userIds.length; j++) {
            if (userIds[i] > userIds[j]) {
                (userIds[i], userIds[j]) = (userIds[j], userIds[i]);
            }
        }
    }
}

这冒泡排序每次交换都要两次SSTORE，gas费爆炸。实际开发中，尽量把排序放到链下。

EVM的存储限制决定了动态数组的玩法。每个槽256位，最大长度2^256-1，但gas费和区块gas限制让你用不了那么大。实际中，数组超几千个元素，操作就慢得像乌龟了。

每次SSTORE都会改EVM的状态树（Patricia Merkle Trie），增加区块的存储开销。动态数组的频繁操作会让状态树膨胀，影响节点同步。所以，大规模数组操作得谨慎。

动态数组的多维复杂应用

多维动态数组咋玩？比如一个二维数组存用户评分：

uint[][] public ratings;

function addRating(uint userId, uint score) public {
    while (ratings.length &lt;= userId) {
        ratings.push(new uint[](0));
    }
    ratings[userId].push(score);
}

这代码动态扩展二维数组，存储槽计算复杂，gas费高得离谱，实际中尽量用映射代替。

EVM的内存管理

memory数组的分配在EVM的内存区域，起始地址从0x80开始，动态增长。new uint[](n)会分配32 + n*32字节，拷贝操作由MSTORE和MCOPY指令完成。memory操作的gas费跟数组大小线性相关，远比storage便宜。

动态数组的冷门坑

还有啥坑？比如storage数组的引用问题：

function badPractice() public {
    uint[] storage ref = userIds;
    ref.push(999);
}

ref是storage引用，直接改userIds。但如果不小心用memory引用，会拷贝数据，改动不影响storage，容易出bug。

动态数组的复杂数据结构

最后来个大招：用动态数组实现一个简单的链上数据库，存用户和他们的交易记录：

pragma solidity ^0.8.0;

contract UserDatabase {
    struct Transaction {
        uint amount;
        uint timestamp;
    }

    struct User {
        address userAddress;
        Transaction[] transactions;
    }

    User[] public users;

    function addUser(address _userAddress) public {
        users.push(User(_userAddress, new Transaction[](0)));
    }

    function addTransaction(uint userIndex, uint amount) public {
        require(userIndex &lt; users.length, "Invalid user");
        users[userIndex].transactions.push(Transaction(amount, block.timestamp));
    }

    function getUserTransactions(uint userIndex) public view returns (Transaction[] memory) {
        return users[userIndex].transactions;
    }
}

这代码用动态数组嵌套，存用户和交易历史。getUserTransactions返回整个数组，gas费高，适合小数据量。

字节码的终极分析

再看个pop的字节码：

SLOAD 0x0           // 读长度
DUP1                // 复制长度
PUSH1 0x0           // 推入0
EQ                  // 检查长度==0
JUMPI               // 如果0，抛错
SUB                 // 长度-1
DUP1                // 复制新长度
SHA3                // 计算最后一个元素位置
ADD                 // 加上索引
PUSH1 0x0           // 推入0
SSTORE              // 清零
SSTORE 0x0          // 更新长度

每步都在烧gas，SHA3和SSTORE是主力。想省gas？尽量批量操作，少用循环。

原创
学分: 0
分类: EVM
标签: Solidity 智能合约 EVM

本文参与登链社区写作激励计划，好文好收益，欢迎正在阅读的你也加入。

Solidity动态数组全攻略：从零到精通，带你窥探EVM底层！

动态数组它到底是个啥？

动态数组的基本操作

动态数组咋存的？

存储槽的布局

push操作的底层

pop操作的细节

读元素的逻辑

内存中的动态数组：完全不同的世界

动态数组的复杂玩法

删除中间元素

批量操作

跟映射结合

动态数组的EVM指令

投票系统合约

多维动态数组

gas和存储的博弈

动态数组的局限

EVM的存储优化

动态数组的复杂应用

动态数组的调用栈

动态数组的边界情况

动态数组的排序

动态数组的多维复杂应用

EVM的内存管理

动态数组的冷门坑

动态数组的复杂数据结构

字节码的终极分析

0 条评论

文章目录