代币授权是让指定对象按代币合约规则动用某个账户的代币，常见 ERC-20 操作称为 Approve；ERC-20 是代币接口标准。连接网站不等于批准支出；断开连接也不会自动撤销额度。以太坊提案 EIP-20 定义了额度查询与动用，EIP-2612 则让符合条件的签名创建额度。本文用有限额情境说明生效、动用与撤销，数据核对至 2026 年 10 月 27 日。
看见钱包跳出确认窗口，最难的往往不是找按钮，而是弄清楚自己正在答应什么。网站说「登录」，画面却要你同意一笔交易；网站已经断线，某个对象的代币额度却还留在链上。这些差别如果只用「有没有连上钱包」判断，很容易漏掉真正的支出权限。
这篇先拆开连接、交易与签名，再走完一份有限额计划。重点是每一步完成后，哪些状态真的改变，以及还有哪些事不能因此声明安全。
钱包连接、交易与签名，授予的权限不同
连接、Approve 与消息签名是不同动作，不能共用一个「已授权」的结论。 一般网站连接可能取得用户选择公开的账户地址，并提出后续请求；能提出请求，不代表已经获得任意转走资产的能力。钱包本身如何保管密钥，可先看本站的钱包与控制权。
连接网站，不等于已批准代币支出
常见 ERC-20 代币把动用额度记在代币合约里。持有人先给某个 spender 额度，对方才可能依规则调用 transferFrom，把持有人代币转给指定接收者。Spender 是被授权动用的地址，可以是合约，也可能是一般账户；不能只凭它叫「路由器」就判定可信。
MetaMask 官方〈Disconnect wallet from a dapp〉提醒，断开网站连接不会撤销代币授权。断线处理界面连接，撤销则要改变链上额度。使用硬件签名也不会自动拒绝恶意支出要求；硬件的密钥隔离解决部分取钥风险，仍需要用户理解签名内容。
Approve与Permit，生效时点要分开
Approve 通常是一笔送到代币合约的交易。按下确认后，仍要等它在链上成功执行，才能说额度已改成新值；拒绝签署、尚未送出、等待处理与执行失败，都不能直接记成完成。
另一种路径是 Permit。EIP-2612 定义的 Permit，让持有人先对特定数据签名，再由自己或其他人提交链上。Gas 是链上执行的计费用量；签名当下可以不产生链上 Gas 费，却可能让之后提交的人创建额度。因此「这次没有扣网络费」不能用来判断签名没有资产风险。其他协议还可能有自己的签名与动用机制，不能全套用同一种撤销方式。
读懂一笔授权，要固定哪四项数据
查额度前，先固定网络、持有人、代币合约与被授权方。 少一项，就可能查到另一条链、另一个账户或另一份代币合约，看到零却误以为自己要处理的权限已清掉。
网络、持有人、代币与被授权方
持有人是代币由谁的账户支出；代币合约决定查哪一种代币；被授权方则回答谁能依额度动用代币。接收者可以与被授权方不同，不能把画面上的最终收款地址直接当成 spender。
EIP-20 的 allowance(owner, spender) 查找本来就以持有人与 spender 为参数，而且是在指定代币合约上执行。同名代币不是同一份合约，同样外观的地址也不能省略网络确认。从可信的官方入口查出完整数据，再与待签内容比对，才知道这一笔准备改哪个状态。
额度不是余额，无限额也不是免费
余额是账户目前持有多少；额度是指定对象依合约规则最多能动用多少。授权 20，不会因此把余额增加 20，也不表示已立即转出 20。额度高于目前余额时，风险还可能延伸到日后转入的代币。
画面显示无限额或很大的数字，主要改变的是允许动用范围，不是免除手续费。不同代币对最大额度、额度扣减或修改方式可能有不同实现方式；下面固定使用会随成功动用扣减的有限额模型，不拿它代表所有 ERC-20 代币。若操作只需要 12，仍应先理解为什么要求更大的额度，而不是因为下一次方便就跳过范围确认。
有限额演练：20、8与0分别在哪一刻成立
把额度与余额分开记，才能看出每一步到底完成了什么。 以下是纸上教学：持有人 A 起初有 100 单位的代币 T，准备让对象 S 动用其中 12，最后撤销剩余额度。A、S、T、接收者 R 都是代号，没有真实部署、签名或转账；也没有代币价格与获利假设。
第一步：先读目前额度，再决定操作
先固定本例网络、A、T 的合约与 S，查到目前额度为 0。把这个结果连同查询时点记下，才进一步看操作是否真的需要 S 代为动用，以及 S 是否与可信界面所列的地址一致。查到 0 只能说此刻这一组数据的链上额度为零，不能证明 A 没有其他授权或有效签名。
本例计划只给 20，预定动用 12，并在动用完成后处理剩余额度。20 是教学选择，不是建议每个人都用相同限额。若待签窗口改成另一个 S，或代币不再是 T，就取消这次准备，回到四项数据重新核对，不用「刚才已经查过」放行不同要求。
第二步：只批准20，等链上确认
假设 A 准备送出把 T 对 S 的额度设为 20 的 Approve，还要核对交易对象、调用内容及网络费。这里的 20 是代币显示单位；合约可能以更小的整数单位保存，要由可信界面依该代币的小数位数正确换算，不能把原始整数直接当成画面数量。
在「签名完成但尚未确认」的阶段，记录应写等待，不能先把额度填成 20。等交易成功，再查同一组数据得到 20，才把状态改成已生效。这一步没有移动 T，因此本例余额仍是 100；若由 A 自付网络费，原生币余额可能另行减少，不能混成 T 被动用了。
第三步：动用12之后，核对剩余额度8
假设 S 依本例规则成功把 A 的 12 单位 T 转给 R，且没有其他代币变动。此时 A 的 T 余额是 100 − 12＝88；在本篇采用的有限额扣减规则下，S 的剩余额度是 20 − 12＝8。两个数字不同，正好分别回答「还持有多少」与「对方还能动用多少」。
确认时不能只看操作页的勾号。要查原交易是否成功、实际代币与接收者是否正确，再读目前余额及额度。若这段期间有另一笔动用或转账，88 与 8 就不再能直接套用；如果执行失败，则按实际链上状态记录，不能照预期把 12 扣掉。
这一步也提醒你：一般 ERC-20 额度依所授予的权限运作，不等于已把接收者或每次用途锁死。除非合约另有限制，不能因为第一次送给 R，就假设剩下的 8 永远只能用在同一个地方。
第四步：撤销并确认0，别只看已送出
接下来假设 A 成功把同一组 T、S 额度改为 0。撤销交易等待期间，原本的 8 不会因为你已按按钮就自动失效；对方的动用与撤销何者先被执行，仍影响最后结果。不要把「已送出撤销」写成「资产已安全」。
只有在撤销成功，并重新查到额度为 0 之后，才记为这一组链上额度已归零。在没有其他 T 变动的教学假设下，A 仍持有 88，不会因为取消 8 的权限就再退回 8。这是关闭剩余动用额度，既不追回已转出的 12，也不替其他权限作保证。
EIP-20 对修改既有非零额度也提示了交易排序风险，并提出界面先设为零再设新值的做法。实际代币可能另有增减额度方法或限制。不要把这个提示当成能阻止所有抢先动用的保证；若已疑似被攻击，应按暴露情况重新评估，而不是一直把限额换成别的数字。
撤销了一笔额度，哪些风险还在
撤销处理的是特定权限，不会自动消除其他签名、其他代币或密钥曝光。 本例完成的只有固定网络上，A 持有的 T 对 S 额度归零。换成另一个 spender、另一条链或另一种资产，就需要另查。
未提交的Permit，与已存在的额度分开
现在加入一个独立分支：A 曾签过一份尚未提交的 EIP-2612 Permit。如果其 nonce 与期限等条件仍符合合约要求，它之后仍可能被提交，用来创建指定额度。Nonce 是防止同一许可重复使用的序号；deadline 是允许提交的截止条件，不是看到日期还没到就可以放心。
这就是为什么查到 Approve 额度为 0，不能进一步推论所有未提交的签名都失效。要看实际协议、许可内容与取消方法；一般 approve(0) 并不自动取消所有种类的签名。上述 20→8→0 的演练没有 Permit 介入，这里是用来说明额度归零的结论边界，不是宣称那份教学已发生第二次动用。
私钥泄露，撤销额度不能换掉控制权
如果助记词或私钥已经交给别人，问题超出某个 S 的额度。持有控制材料的人可能再创建交易或授权，旧 App 改密码也不会把对方的副本收回。可以接着看私钥与助记词差别，确认哪些账户共用同一份来源。
此时不宜只拿一张「已撤销」截屏就结案；同样也不能因为找到可疑授权，就认定私钥必定泄露。应把已知曝光与仍不清楚的部分分开，按实际线索处理。可疑转账与控制权排查，会接续这个分流。
把授权管理做成每次签名前的习惯
最有用的习惯，是在每次答应之前说得出对象、范围与生效方式。 事后盘点可以找出闲置额度，却不能替下一个不明签名预先背书。只要画面无法辨认、数据不一致或网站催促略过核对，就先停止。
从可信入口检查，不接陌生验证要求
从自己核对过的钱包、官方文档或可信额度管理入口开始，不点陌生私信提供的「安全检查」。查公开额度不需要向客服交出助记词或私钥。管理工具若要求签名或交易，要重新读那次内容，不能因为工具标榜安全就视为例外。
MetaMask 官方〈Spending caps〉介绍查阅与撤销支出额度的用途，但工具能列出哪些权限，仍受支持范围限制。某个清单没有列到，不等于不存在其他链、非同质化代币（NFT）的操作权限或协议特有的签名；本篇的 ERC-20 演练也不能直接代替它们的处理规则。
网络费与取消条件一起核对
Approve 与撤销通常需要链上交易费；签名型许可则可能把提交费用交给另一个人。费用由谁付，与你允许谁动用代币，是两个不同问题。失败交易的费用判断，会把准备额与实际扣费拆开。
如果只是例行管理，先确认费用与预算，再决定是否操作；如果已疑似有自动扫币程序，不能直接往旧账户补原生币来「完成撤销」。自动扫币程序会监看充值并自动迅速移走资产。停止条件和额度一起写进计划，才能避免为了处理一笔权限，反而再暴露新的资产。
本文为机制说明与假设情境，未执行真实授权或撤销，不构成个人资产处置建议。代币与协议的实现方式可能不同；有疑似失守事件时，应按实际数据与可信官方支持判断。