通过一次仅有 1 wei 的极简以太币转账，手把手拆解 etherscan 交易页面里的所有字段，让你瞬间读懂 Gas 费用、Gas Price、Base Fee、Priority Fee 到底怎样影响交易成本，以及为什么有时候明明只是“转账”，Gas 消耗却不止 21000。
背景：为什么 1 wei 的转账截图值得研究？
当我们在 Remix 中把 1 wei 发送到某个合约的 receive() 函数时，etherscan 给出的 Transaction Details 页面看似信息量巨大，让人摸不着头脑。本文以 Goerli 的一次真实交易为例，聚焦 Gas、Gas Price、Gas Limit、Transaction Fee、Burnt & Txn Savings Fee 等字段，层层拆解其计算方式，并给出可复用的脚本，让你随时验证自己的理解。
区块链浏览器字段全解析
1. 交易概要与 value 字段
- value：1 wei
合约最终收到的以太币数量，微乎其微，却因 Ethereum 精度 18 位仍能精确记账。
2. Gas Limit & Usage by Txn
- Gas Limit：300000
发送方设定的 Gas 上限，防止未知调用耗尽账户余额。 - Usage by Txn：21055
实际消耗的 Gas 数量。为什么是 21055 而不是 21000？因为转入非 EOA 地址、命中receive()或fallback()时，会追加：MSTORE内存付费- 若干 PUSH、CALL、RETURN 等指令
→ 额外 55 Gas 就这样被“偷偷”烧掉了。
3. Gas Fee 公式的三种组成
在 EIP-1559 时代，Gas Price ≠ 单一价格，而是如下公式：
Effective Gas Price = min(BaseFee + MaxPriorityFee, MaxFee)
| 名称 | 作用 | 去向及意义 |
|---|---|---|
| BaseFee | 由前一个区块市场定价 | 直接烧毁，减少 ETH 通胀 |
| MaxPriorityFee | 用户自愿给矿工的“小费” | 越高矿池越早打包 |
| MaxFee | 用户愿意承受的 Gas 单价上限 | 防止区块拥挤时费用无限制上涨 |
交易截图中：
- BaseFee：
0.000000111 Gwei - MaxPriority：
1 Gwei - MaxFee：
1.5 Gwei
代入公式得出：
Effective Gas Price = 1.000000111 Gwei < 1.5 Gwei（上限）
4. Transaction Fee 计算
Transaction Fee = Usage × Effective Gas Price
- 消耗 21055 Gas，实际单价 1.000000111 Gwei
- 对应 ETH 额度：
0.000000001000000111 * 21055 ≈ 0.000021055002337105 ETH
在浏览器里，你常看到的 Transaction Fee ≈ 0.000021055 ETH 就是这么来的。
5. Burnt & Txn Savings Fee
EIP-1559 把 BaseFee 部分永久销毁，因此：
-
Burnt Fee
BaseFee × Usage =0.000000111 Gwei * 21055 = 0.000000000002337105 ETH -
Txn Savings Fee（省下的 Gas）
(MaxFee − Effective) × Usage
(1.5 − 1.000000111) Gwei * 21055 ≈ 0.000010527497662895 ETH
这笔差额会原路退回发送方，而非矿工额外收获。
6. 空 Input Data 的含义
Input Data 为空 ⇒ 不携带任何 calldata，说明这是 单纯转账，即便目标是一个带有 receive() 的合约，也依旧被标记为普通 ETH 转账，而非合约部署或函数调用。
实例场景：调试合约时如何验证数据？
在真实开发中，我们常用 ethers.js v6 把链上数据拉下来比对。以下代码在 Goerli 执行，可直接复制到 Node.js 或浏览器环境：
(async () => {
const provider = new ethers.JsonRpcProvider(
'https://eth-goerli.alchemyapi.io/v2/demo'
);
const block = await provider.getBlock(8871803, false);
const tx = await provider.getTransaction(
'0xf836049be423723eba16b00b84ecfbfde4c98e10a57c153426bd8834a7136a43'
);
console.log('BaseFeePerGas :', block.baseFeePerGas.toString());
console.log('MaxPriorityFeePerGas :', tx.maxPriorityFeePerGas.toString());
console.log('MaxFeePerGas :', tx.maxFeePerGas.toString());
})();
输出完全与 etherscan 的计算结果对上号，进一步增强对浏览器页的 数据可信度。
深入：为什么不是固定 21000？
很多人第一次听说 21000 Gas 这一“经典值”，却忘记它仅适用于：
- EOA → EOA 转账，且无任何额外操作；
- Input Data 大小为 0；
- 接收方无代码触发。
任何多出一点的操作，Gas 就会按比例增加。👉 点击了解 10 个常被忽视的 Gas 优化技巧，让你的合约少花 gas 还能提速
FAQ：你可能最关心的 5 个问题
Q1：BaseFee 会不会比 MaxFee 还高？
A：会。若 BaseFee 持续上涨，且不设 MaxFee，Transaction 可能被网络丢弃，直到 BaseFee 回落或你手动重新广播。
Q2：我可以把 MaxPriorityFee 设为 0 吗？
A：可以，不过矿工会优先打包给“小费”更高的交易，你就只能慢慢排队。
Q3：如何手动设置这三项费用的最佳数值？
A：参考以太坊主网或测试网的 gasnow 实时数据。MetaMask 也会给出智能推荐。
Q4：为什么 Remix 打包建议的 21055 Gas 比浏览器多？
A：浏览器展示的 Usage 与 Remix 的 Gas Estimation 有微差，相差几十 Gas 大多源于内存扩展、JUMPDEST 等细节。
Q5：把 receive() 换成 fallback() 会影响吗？
A：会。fallback() 可能接收更多 calldata，Gas 开销更高；而 receive() 只处理 最小操作码集合，更省 Gas。
省流总结
- 交易页面里 Min、BaseFee、MaxPriority、MaxFee 四个字段组成 EIP-1559 的 多维度 Gas 计算。
- 21055 Gas vs 21000 Gas 的差别，是合约
receive()带来的 55 Gas 隐含消耗。 - 巧用 ethers.js v6 可对照浏览器页，瞬间验证链上所有字段。
