Solidity中mapping结合SHA-3的存储寻址工作原理是怎样的？

你产生这个困惑，本质是两个基础认知有偏差：一是把EVM的链上存储逻辑和传统程序的连续内存分配机制搞混了，二是对mapping的哈希计算规则了解不完整。

• 第一，先搞清楚存储载体：mapping的本体永远存在合约的持久化存储storage里，根本不是存在运行时内存（memory）中。EVM给合约分配的storage是一个理论寻址空间高达2^256的稀疏键值结构，每个地址对应一个32字节的存储槽。这个空间完全不需要提前预分配，只有你实际写入过的槽位，节点才会真正存下对应数据，从来没碰过的槽位默认返回0，根本不占实际存储资源。
• 第二，哈希值和寻址空间是完全匹配的：Solidity里计算存储位置用的Keccak256（很多教程俗称SHA-3），输出结果刚好是固定256位长度，正好覆盖了storage全部2^256个槽位的编号范围。说白了算出来的哈希值本身就是槽位号，根本不存在“随机值找不到对应位置”的问题——整个寻址空间本来就装得下所有可能的256位哈希结果。
• 第三，真实的寻址计算不是只哈希键：实际计算存储位置的时候，会先取这个mapping在合约里声明时分配到的专属起始槽位号s，把用户传入的键k和s按编码规则拼在一起再做哈希，最终值的存储位置就是keccak256(abi.encodePacked(k, s))。这么做一是能保证不同mapping之间不会出现存储位置冲突，二是依托2^256的超大空间，现实里几乎不可能出现两个不同输入算出同一个槽位的哈希碰撞。

纠正一个普遍误解：根本不需要“哈希值对应提前分配好的真实物理内存块”。EVM的storage本身就不是按连续内存块管理的，本质就是个全局的超大哈希表，你算出哪个槽位号，就直接去对应位置读写就行，完全不需要提前给这个位置申请分配空间。

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