ERC-2612 Permit授权怎么验？

Permit把“先发approve、再调用应用”的两笔链上操作，改成持有人先离线签名、之后由任意地址把签名提交给代币合约。它节省的是授权交易，不是取消授权风险。签名一旦泄露，提交者无需是owner，也无需得到owner再次确认。

一份Permit从签署到消费

第一阶段，应用读取owner当前nonce和代币DOMAIN_SEPARATOR，构造Permit结构；第二阶段，owner的钱包签下EIP-712摘要；第三阶段，应用或中继者调用permit，把v、r、s连同参数交给代币合约。合约验证成功后更新allowance并递增nonce，随后应用才调用transferFrom消费额度。

这个顺序解释了两个常见现象：用户签名时钱包里不必有原生币，因为签名不上链；签名提交者却要支付链上Gas，除非应用替他承担。

参数	应核对的实际问题	验证失败的常见原因
owner	哪个地址授权	钱包切换了账户
spender	谁能花代币	前端指向了错误路由或恶意地址
value	最大可花额度	单位缩放错误或使用无限额度
nonce	当前签名序号	另一份Permit先被执行
deadline	最晚提交时间	节点时间已超过期限

nonce和deadline防的是不同问题

nonce让同一个owner的签名按序消费。某份Permit成功后，该owner的nonce变化，旧签名就不能再次通过。deadline只限制提交时间；设置很远的deadline不会替代nonce，设置很近则可能因为排队或跨链操作超时。二者还必须连同chainId、代币合约和域版本一起进入摘要。

Permit本身不会转走代币，也不会在业务完成后自动把allowance归零。若value远大于本次需要，即使应用只消费一小部分，剩余额度仍由spender控制。用户应把spender核对到完整地址，能用精确额度时不签无限额度，并在不再使用时主动撤销。

为什么同名“Permit”会不兼容

ERC-2612规定permit(owner,spender,value,deadline,v,r,s)、nonces和DOMAIN_SEPARATOR，但市场上还有DAI式Permit、Uniswap Permit2及项目自定义签名。它们的字段、nonce空间与授权对象不同。前端不能只检测函数名，也不能把一份ABI套在所有代币上；至少应读取已验证源码或官方接口，并用eth_call模拟。

遇到invalid signature时，按顺序排查：确认签名账户与owner一致；重新读取nonce；核对chainId和verifyingContract；检查钱包是否改变了字段顺序或类型；最后确认代币确实实现ERC-2612。不要通过反复扩大value、延长deadline来“修复”验签。

Permit的底层域分离可继续看EIP-712签名核对，合约钱包验签需结合ERC-1271，撤销和连接风险可参考智能合约连接检查。