锁住一枚 NFT：ERC-5753 的钥匙交给谁，和 ERC-5192 差在哪

“这枚代币被锁定了”是一句歧义很大的话：可能永远解不开，也可能钥匙在某个合约手里。ERC-5192 和 ERC-5753 正好对应这两种语义。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对：ERC-5192 标注 Final，ERC-5753 标注 Stagnant。

两种接口，两种答案

ERC-5192 极其精简，灵魂绑定代币只需要回答一个问题：locked(tokenId) 返回真假，外加一个 TransferLocked 事件记录“被锁定的代币又挪了窝”——因为即使不可转移，代币也可能因合约迁移、账户重构等原因换地址，事件负责让索引器跟得上。它不定义谁有权锁、怎么解锁，语义偏向“这东西就是不再流通了”。

ERC-5753 则把锁定做成一场有钥匙的交接：lock(unlocker, id) 把一枚 ERC-721 交给某个解锁人地址看管，getLocked(tokenId) 返回当前保管人地址、未锁定时返回零地址，unlock(id) 只有当初登记的保管人才能调用。规则写得很硬：代币处于锁定状态时，所有 ERC-721 转账函数必须回退，唯一的例外是这笔交易由保管人本人发起。配套的 Lock 与 Unlock 事件把交接过程记在日志里。一个直观的官方用例是元宇宙活动票：入场核销后立刻锁住，防止同一张票转卖造成双重使用，而抬杆权在主办方合约手里，活动结束再解锁归还市场。

核验一枚锁定代币的实际路径

在浏览器上对着合约页逐项问：先试 ERC-5192 的 locked——返回真且没有任何解锁函数，才接近“永久绑魂”；再试 ERC-5753 的 getLocked——返回某个非零地址，说明是“代管锁”，此时要追问三件事：保管人合约是公开可验证的代码还是权限集中的后台、解锁条件是否写进了合约、保管人地址会不会被项目方换掉。两种锁的信任代价完全不同：前者把自由交给代码，后者把自由交给一个合约乃至一个团队。

事件索引与边界案例

对做数据面板的团队，两把锁的事件流长得完全不同。ERC-5192 的 TransferLocked 会告诉你一枚“本该不动”的代币刚刚换了主人，常见诱因是合集合约迁移或空投脚本误操作，收到它应当触发人工复核而不是报警转账失败；ERC-5753 的 Lock 与 Unlock 则成对出现，保管人地址直接写在事件里，可以按保管人聚类出“哪些项目在用代管锁”。边界案例也要提前想：代币被 ERC-5753 锁住期间，approve 调用仍然可以发生——锁定拦的是转账函数，不是授权簿记，因此“币被锁着却被别人划走”并非不可能，取决于市场结算用的是哪条通道；反过来，ERC-5192 的不可转让并不阻止合约层面的强制销毁或迁移，除非实现方另行编码。把这些细节核对清楚，才知道两种锁各自在防什么、又不防什么。

与 ERC-6454、ERC-7066 的对照位

“锁”这个词在标准世界还有几间近邻房间：ERC-6454 问的是“转账本身被策略禁了吗”，把判断委托给独立的转账守卫合约；ERC-7066 则在 ERC-721 上加一个按代币的锁座位，允许持有人自己开关。ERC-5753 的特色是“第三方保管人”语义——锁的目的往往是担保、租卖双防或活动核销，钥匙天然不该在持有人口袋里。三种模型没有优劣，只有场景匹配；而无论采用哪种，标准都只是接口外形，真正的信任量都藏在“谁实现、代码是否已验证、权限可否变更”这三个非标准问题里。

一句选择口诀

判断产品该用哪把锁，可以浓缩成一句话：永久不再流通用 5192，暂时代管等赎回用 5753，策略与开关混合需求再看 6454 与 7066。口诀只解决方向，落地仍要读目标合约的已验证代码。

还要提醒 Stagnant 的含义：ERC-5753 处于停滞状态，不表示接口有错，而是推进停滞，实际部署的版本可能冻结在早期文本，接口细节务必以目标合约的已验证源码为准，而不是照抄文档。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。