交易里的 deadline 参数按什么单位生效：填错一格还没执行就注定回滚

兑换、领取、授权这几类操作里常见一个名叫 deadline 的参数，界面默认值往往是“当前时间往后几分钟”。有人把它随手改大，有人改成未来某个区块高度，结果要么保护窗口形同虚设，要么交易一上链就整体回滚。这个字段按什么单位生效、填错后链上会发生什么，值得一次讲清。

deadline 比的是时间戳，不是区块高度

以链上最常见的两类写法为例。Uniswap V2 路由器在每个兑换函数入口检查传入的 deadline 是否不小于当前区块时间戳（block.timestamp），不满足就以 UniswapV2Router: EXPIRED 整体回滚；ERC-2612 的 permit 离线授权同样要求“当前区块时间小于等于 deadline”才生效。两处判断的尺子都是秒级 Unix 时间戳，而不是区块编号。这就解释了最常见的翻车：有人把“当前区块号加 500”填进 deadline——区块号在 2026 年已经是一个远大于任何时间戳的量级，这样填等于给了一个遥远未来的过期时间，保护窗口被拉到几十年，等于没填。反过来，把时间戳当区块号理解、只加了个位数的人，则可能在排队几分钟后发现交易被打包时已过了期限，整笔调用回滚。

回滚不是小事故

deadline 检查失败属于业务逻辑回滚：交易照样上链、Gas 照样扣，只是兑换、领取或授权动作一件没发生。它和签名错误被节点拒收是两种结局——后者根本不会出现在浏览器里，前者会留下一条状态为失败的正式记录，查询方法见区块浏览器交易详情页怎么读？转账成功不成功一看便知里的回执字段。对价格敏感的交易来说，过期回滚至少损失一笔手续费；对授权场景来说，更麻烦的是你以为额度已改，链上实际没改。

那“到期自动失效的授权”到底存不存在

标准的 ERC-20 授权本身没有时间参数：approve 只是把允许额度覆盖写成新值，没有任何一格数据在记录“何时作废”。带到期语义的授权走的是另外两条路：一条是 ERC-2612 这类离线签名授权，签名里带 deadline，过了时间戳谁提交都无效，额度本身并不会到期消失，只是这份签名作废；另一条是个别代币实现的“expiring approval”，把过期时间存进额度槽，由转账逻辑在执行时自行检查。普通用户想给授权加保险，现实做法仍然是三档：只给当次用量的最小额度、定期用零额度覆盖写回收（操作口径与代币授权怎么批量撤销？撤销交易的手续费、顺序与生效确认一致）、优先使用支持限时签名的产品并读懂ERC-2612 Permit授权怎么验？里的字段。

时间戳这个尺子本身也要留意

区块时间戳由打包节点写入，协议只允许它小幅偏离真实时间，不同链的出块节奏不同：有的链十几秒一个块，有的以分钟计。对 deadline 的实际含义是——同一段“留十分钟余量”的设置，在快链上跨过几十个块、在慢链上可能连一个块都没等到。另外，节点时间与协调世界时的同步偏差会整体平移这把尺子，个别环境下偏差可达几十秒。这些都不是需要普通用户操心的部分，但它们解释了同一种填法为什么在不同链、不同时段得到不同结果：deadline 从来不是“这笔交易能不能被执行”的保证，而是“超过这个时刻就宁可不执行”的止损开关。把它理解成排队等待时间，方向就完全反了。

填错之前的三秒自查

发送前确认三件事：deadline 用的是时间戳单位；留的余量足够交易排队（几分钟到几十分钟量级，而不是一个区块的量级）；对价格波动大的兑换，滑点下限与 deadline 同时有效，别只调一个。执行后若看到失败回执，先读回滚原因里是 EXPIRED 还是金额类报错，两者指向的修正方向完全不同。

本文仅作合约参数机制科普，不构成任何投资建议或操作收益承诺；涉及真实资产请先小额演练。