Gas 把网络资源转换成交易成本
Gas 用于衡量执行交易或智能合约需要的网络资源。费用通常由消耗的 Gas 与当前费率共同决定，因此简单转账和复杂合约调用的成本可能差异很大。
估算只是提交前参考，实际使用量以执行结果为准。
Gas limit 与费率解决不同问题
Gas limit 约束交易最多可使用多少执行资源，费率则影响用户愿意为每单位资源支付多少。设得过低可能导致执行不足或长时间等待，设得过高也不代表一定会全部消耗。
具体字段名称因网络实现而异。
nonce 会影响同一账户交易的顺序
许多 EVM 网络为账户交易使用递增 nonce。同一账户的较早交易如果长期待处理，后续交易可能也受到影响。
遇到多笔 pending 时，应先检查 nonce 顺序，而不是只比较时间。
确认数从交易进入区块后开始累积
交易被打包进区块后获得第一个确认，后续区块继续增加确认数。不同应用可能要求不同的确认深度。
确认速度受出块、网络拥堵和最终性机制影响。
交易哈希可以解释“钱扣了但对方没看到”
使用正确网络的浏览器查看状态、区块、接收方、Gas 使用量和执行结果，可以区分待确认、失败和已经成功但对方界面未刷新的情况。
没有交易哈希时，先确认交易是否真正广播。
加速、替换或取消不是所有网络都一样
部分网络允许通过相同 nonce 和更高费用替换待处理交易，但规则取决于网络与钱包实现。已确认交易通常无法用这种方式撤回。
操作前应确认当前交易仍处于可替换状态。
费用不是成功承诺
支付更高费用可能提高被打包的竞争力，但不能替代对合约逻辑、网络状态和交易内容的检查。
费用和确认问题按状态排查
先查交易是否生成哈希；有哈希则看是否 pending、失败或已确认。pending 时再检查费率、nonce 和网络拥堵；失败时查看执行结果；已确认则核对接收方和资产显示。
先判断状态，再决定是否调整费用
不要因为“很久没到账”直接再次发送同样金额。先确定原交易的链上状态，避免重复支付或产生冲突 nonce。
- 提交前确认有足够原生 Gas 资产。
- 多笔交易待处理时检查 nonce 顺序。
- 用交易哈希区分 pending、failed 与 confirmed。
- 已确认交易通常不能通过提高费用来撤回。