V3.05.2Request-grant handover设计
控制权交接需要请求与授予两个独立动作
别名: 请求-授予模式 · 两步交接 · 控制权协商
概念解释
控制权的规范化交接是两个独立动作：想要的人先请求，持有的人再授予。一步完成的交接（直接抢、自动转）把两件事压缩成一件，省了时间却丢了两个信息——持有者不知道有人想要（被抢时措手不及），请求者不知道对方是否知情（拿到的是默认还是许可）。请求-授予把交接变成一次显式协商，双方都在知情状态下完成权力转移。它与自由抢占不是对错关系，而是不同社交密度下的选择：陌生人或正式场景用两步，熟人高频协作用一步加事后提示。
机制
两步交接保护的是持有者的上下文。操作权持有期间，人正在一套动作序列中间（输入到一半、演示到关键处、远程操作进行中）；被直接抢占意味着动作被打断在任意点，未完成的输入悬在半空，恢复成本由双方共担。请求-授予把打断点交还给持有者选择：看到请求后，他可以把当前操作收尾、把状态整理好、甚至口头交代上下文，再交出去——交接从「随机截断」变成「干净切换」。对请求者，等待授予的时间买到了进入时的完整状态：接手的是持有者整理过的局面，而不是半截操作。两步的成本是延迟，而延迟只有对操作密集、节奏极快的任务才真正构成伤害——大多数协作场景里，一次干净的交接省下的恢复时间远大于等待的那几秒。
边界
请求-授予不适合所有节奏。操作密集且实时性要求高的场景（远程协助里客户急着让支持人员上手），两步协商的延迟本身就是伤害，应允许预设授权（会话开始即授予支持方）或快速通道（请求即临时获得，持有者可收回）。角色不对等的场景（主持人与听众）也不必两步——主持人可以单方面移交并随时收回，请求-授予是平等主体间的机制。请求被无视是两步模式的固有问题：持有者不响应时不能无限等待，需要有超时与升级路径（自动转给请求者、或主持人仲裁）。
怎么落地
- 请求动作要轻（一个按钮、一个快捷键），授予动作要显式（点击确认，而非超时默认视为授予）。
- 请求到达时持有者界面给出不打断当前操作的温和提示（角标、声音），由他选择何时处理。
- 授予完成后双方都收到确认，且新持有者立即获得完整的操作上下文（当前状态、被交接对象的焦点位置）。
- 为请求设置超时与升级：长时间无响应可转由主持人仲裁或按预设规则转移，避免死等。
- 验证：录屏统计交接事件——请求到授予的时长分布、交接后 30 秒内的误操作次数；误操作集中在交接点附近说明上下文传递不完整。