Z4.08.2Automatic access expiry设计
临时授权到期后需要自动收回而非依赖手动撤销
别名: 自动收回 · 到期失效 · auto-revoke
概念解释
授权应当有寿命，而且寿命要由系统执行：到期即失效，不需要任何人记得去按「撤销」。把撤销做成手动步骤，是设计者把自己该做的事转成了用户的待办——而这份待办没有提醒、没有可见性、没有截止时间，结果可预期地永远不会被完成。
这条与「授权创建时默认限时」是相邻的两半：那条管授予时的范围与寿命设定，这条管寿命尽头的执行机制——为什么收回必须是自动的、自动收回要处理好哪些边界。
机制
手动撤销为什么结构性失败？三个各自充分的原因。
没有触发事件。 撤销任务在人的待办体系里排不上队：访客离开不产生任何系统事件（除非授权挂在外部锚点上），主人的注意力不会被拉回这件事。没有触发器的任务只靠随机想起——这就是为什么残留授权能存活数月。
对象不可见。 已授权的访客凭据不占用任何日常注意（不通知、不显示、不干扰），「看不见的东西不会被想起」是注意的默认规律。手动撤销要求主人对一个长期不可见的对象保持惦记。
社交成本阻止执行。 撤销一个具体的人，是一个社交动作——「删掉朋友的权限」读起来像绝交。哪怕关系早已淡化，主动收回仍要跨越一个说不过去的门槛，于是被无限推迟。自动到期把这层社交拿掉了：收回是系统按规则做的，不是主人对某人做的——「门锁过期了」比「我把你删了」好说得太多。机制在这里做的是社交语义的转译。
自动收回的正确形态因此是：到期由系统时钟或外部锚点（订单退房、日历事件）触发，凭据失效产生记录（何时、谁、哪项），撤销不依赖任何人的行动。
边界
- 硬截止在边缘上是恶意的。 航班延误、住客晚走——中午十二点整准时反锁门外，是把规则执行成了敌意。自动收回必须配宽限期与一键延期：到期转窄门（需主人确认）而非立即落锁；延期操作要能在手机上三秒完成，否则主人会提前给永久权限来避免麻烦。
- 共享凭据逃脱整个模型。 访客如果拿到的是主人自己也在用的密码/PIN，到期收回无从谈起——改密码会把所有人一起踢下线，于是不改。每人一份独立凭据是自动收回的前提条件，键盘码尤其要按人生成。
- 锚点质量决定收回语义。 挂在订单上的到期跟着订单走（改退房自动顺延）；挂在固定时刻的到期跟现实脱节（主人手动改）。能拿到外部锚点就别用裸时间。
怎么落地
- 到期尽量绑定外部锚点：住宿订单、日历事件、预订系统；锚点变更时授权自动跟随。
- 按人发码，绝不共享 PIN：门锁键盘码、一次性链接、NFC 卡片都行——凭据独立，收回才有对象。
- 到期事件记录且可见：「张三的门锁权限今天 12:00 到期」进家庭活动流，让收回这件事至少在发生时可查。
- 到期前 24 小时提醒主人并附一键延期——宽限不是放任，是把例外处理成本降到一次点击。
- 验证办法：渗透式审计——对一批住宿结束后的账号，测试其凭据是否仍然有效，残留率应为零；同时跟踪「因到期被拒之门外」的客诉（宽限期配置过紧的信号）。两个数都健康，自动收回才真正成立。