你在钱包里改了权限，网站凭什么知道：CAIP-311 的会话变更广播事件

授权改动天然是单边的，直到有了这个事件

钱包授权的一个别扭之处：改动几乎都发生在钱包侧。你在钱包的权限页里把某条链从会话里去掉、或者把某个地址从授权账户里撤下，网页对此一无所知，它还拿着旧清单继续显示”已连接、已授权”。编号 311 的链无关协议（CAIP-311）给这条单行道装上了反向通道：它定义了 wallet_sessionChanged 事件，规定钱包在用户于钱包端更新会话授权后，把更新后的授权范围主动推送给会话的另一方。按规范仓库原文核验，该提案目前处于 Draft（草案）状态，是否推送、何时推送取决于钱包实现。

载荷结构：推的是全量清单，不是差值

事件的载荷有两个字段：可选的 sessionId 标明这是哪个会话的变更，必需的 sessionScopes 携带全量更新后的授权清单。关键在于”全量”二字——推的不是”你少了哪一项”，而是”现在完整是什么样”，每条链一个键、里面完整列出方法、通知和账户，格式沿袭 一份 JSON 说清「哪条链、哪些方法、哪几个账户」：CAIP-217 授权作用域语法 定义的作用域对象。全量设计的好处是自愈：应用不需要维护差值运算，任何一次成功接收都能把本地状态拉回事实基线；哪怕上一条事件整批丢失，下一条一到照样归位。这个选择的代价是流量略大，但对会话这种低频事件而言可以忽略。它和会话查询方法 网站记忆和钱包实况对不上？CAIP-312 给会话权限装了一个查询接口 构成一对：一个推、一个拉，两条路殊途同归。

错过事件怎么办：重连即补查的硬规则

规范在定义段里写了一句很硬的纪律：若钱包与调用方连接断裂、存在错过事件的可能，调用方应当立即调用 wallet_getSession 取回当前会话作用域。这条规则把”推送”降级成了加速器而非唯一真相源——事件在，状态更新快；事件丢了，重连后的主动查询兜底。理解这个双层结构，你就能预判不同站点的行为差异：落实规范的站点在你改完权限刷新后会立刻改口；没落实的站点要等你重新发起连接才对齐；两者都没做的，会在你调用一个已被撤掉的方法时突然弹”未授权”。这三种表现本身就是一份不用看源码的合规检测表。

为什么不用重建会话代替事件

在 311 之前，让应用知道权限变了的标准做法是重新走一遍建会话流程—— CAIP-25钱包会话如何申请最小权限？ 讲的会话握手再签一次，等于用最重的手段传递最轻的信息。提案的动机段把这层账算得很直白：目标是让授权调整不必每次都以重建会话为代价，双向管理同一份会话的生命周期。对用户的直观收益是少弹确认窗：会话没有中断、身份没有重认，只是清单更新一条。反过来说，这也意味着你在钱包里改权限的即时后果是”网页可能马上知道”，而不是”网页还会蒙在鼓里一阵”——隐私上这是中性偏好的设计，知情方从只有你变成你和站点两边。

多链会话里的核对细节

sessionScopes 天然多链并存：规范示例里，同一份清单里主网保留着转账与签名两项方法，Polygon 只剩转账，Solana 则单独列着一组只读方法。这提示一个易错点：你在钱包里只去掉了其中一条链的授权，其余链的授权原样保留，事件推送后网站界面可能仍显示”已连接”——连接还在，只是范围瘦了。逐项核对的正确姿势是把推送来的清单和钱包权限页并排比一遍，确认每条链剩什么。多链同址的钱包尤其要逐链看账户字段，避免”这条链撤了、那条链还挂着另一个账户”的错觉，账户与链如何配对可参考 CAIP-10账户ID为什么必须带链？ 的账户标识规则。

现状边界与安全提醒

以落地现状看，311 与它配套的查询、撤销方法同属尚未全面铺开的草案，主流钱包对会话事件推送的支持进度不一，测试办法很朴素：改一次权限，观察网页能否在下一次交互前反映变化。安全层面要提醒两点。其一，事件的方向是钱包到应用，任何反方向”网站通知你它改了你的会话权限”的界面话术都值得警惕——授权的收与改权在钱包一侧，站点没有资格替你改。其二，收到变更提示后如果与你记忆的操作对不上，先冻结该站点的自动请求，去钱包权限页复核，再决定重连还是彻底清除；把会话彻底清掉的操作含义见 点下「撤销连接」之后发生了什么：CAIP-285 与 wallet_revokeSession 的协议动作。涉及资产安全的操作没有捷径，逐项人工确认永远优先于”看起来正常”，本文不构成投资建议。