图片资料：官方来源
在钱包里发一笔以太坊L1普通交易，界面常给出两个数字：Gas上限（gasLimit）和最高单价（maxFeePerGas）。把两者相乘，得到的是一笔交易的执行Gas费用上限，不是最终扣款。实际费用取决于交易真正消耗了多少Gas，以及打包时生效的单价。
预算公式：上限×最高单价
按EIP-1559，普通L1交易的执行Gas费用预算为：
预算 = gasLimit × maxFeePerGas
假设一笔合约交互设gasLimit为80,000，maxFeePerGas为30 gwei：
- 80,000 × 30 gwei = 2,400,000 gwei
- 换算为ETH：2,400,000 × 10⁻⁹ = 0.0024 ETH
这0.0024 ETH是这笔交易在设定参数下的最高可能执行Gas支出，不包括交易转出的本金value。它回答的是“Gas费最多可能花多少”，不回答“实际花了多少”。
实际费用：实际用量×生效单价
交易打包后，费用按实际gasUsed和effectiveGasPrice结算：
实际费用 = gasUsed × effectiveGasPrice
其中：
effectiveGasPrice = min(maxFeePerGas, baseFee + priorityFee)
这里的priorityFee，是交易里maxPriorityFeePerGas设定的上限，不是承诺必付的小费；它同样受maxFeePerGas约束，可能被压到更低。
假设交易实际只用50,000 Gas，打包时baseFee为20 gwei，priorityFee上限为2 gwei：
- baseFee + priorityFee = 22 gwei
- 22 gwei低于maxFeePerGas的30 gwei，生效单价就是22 gwei
- 50,000 × 22 gwei = 1,100,000 gwei = 0.0011 ETH
对比可见：预算0.0024 ETH，实际0.0011 ETH。差额来自两处——Gas上限高于实际用量，最高单价高于生效单价。
未用的Gas不扣费，但上限不是随便设
gasLimit中未被消耗的部分不计费。上例里80,000的限额只用了50,000，剩下30,000不产生费用。设高Gas上限是给执行留余量，防止复杂合约中途耗尽Gas导致回滚。
但这不等于“上限设多高都不影响账单”。在合约执行路径相同、实际用量相同的前提下，提高上限不会直接多收钱；可一旦合约代码读取剩余Gas（例如gasleft）或按可用Gas分支，上限变化就可能改变执行路径，从而改变实际消耗。所以上限应贴着估算值留合理余量，而不是无脑拉满。
真正被全额消耗的情形是执行中途Gas耗尽：EVM回滚状态，但已消耗的Gas照收。上限设得过低有失败风险，设得偏高则可能影响执行逻辑。
几个容易混淆的边界
生效单价等于上限，不等于预算用满。 若实际单价恰好等于maxFeePerGas，说明baseFee加priorityFee已触顶；但总支出是否接近预算，还要看gasUsed是否接近gasLimit。只有两者同时接近，预算才被用满。
交易要被纳入，maxFeePerGas不能低于baseFee。 baseFee由协议按上一区块拥堵情况调整。若等待期间baseFee上涨超过你的上限，交易会滞留待打包，直到价格回落或你取消重发。实际小费为零的交易在协议上可能有效，但是否被打包仍取决于区块构建者。
不含L2额外费用。 上述算法适用于以太坊L1的EIP-1559交易。L2上费用通常还包含向L1提交数据的成本，单价结构也不同，不能直接套用这套乘法。
估算成功不等于执行成功。 钱包给出的Gas估算基于当前状态模拟，打包前链上状态可能变化，合约也可能在特定条件下消耗更多Gas。估算是参考值。
核对一笔交易时看什么
费用与预期不符时，先在区块浏览器打开该笔交易，取gasUsed与effectiveGasPrice相乘，即为实际费用。再对照gasLimit，看差距有多大；若effectiveGasPrice等于maxFeePerGas，说明单价触顶，应结合gasUsed判断预算是否被用满。交易长时间未确认，则检查当前baseFee是否已超过设定的maxFeePerGas。
把“预算”和“实付”分开：前者是参数约束下的Gas费上限，后者是结算结果，中间差额由实际用量和生效单价共同决定。