在功能被使用时请求而非启动时
别名: 即时权限 · 按需请求 · ask on use · contextual permission
概念解释
即时权限请求（just-in-time / ask-on-use permission）把系统授权弹窗放到人已经决定使用某项能力的那一刻：点了「拍照」、要导航到目的地、要开麦说话。启动页、欢迎页、登录后的空屏上连环弹出位置、通知、相册，不属于即时请求。这条只谈请求落在任务流的哪一步，不谈弹窗前怎么写用途、拒绝之后功能怎么降级、权限以后能不能撤回。
机制
人按当前任务判断一项能力是否说得通，而不是按应用清单判断。启动时还没有任务，权限名只是抽象能力（「位置」「相机」），拒绝几乎没有机会成本，允许则像给一张空白支票。任务进行中，同一句「允许访问相机」被锚定在「我正在拍这张收据」，适当性来自情境，而不是来自品牌信任。过早询问还会占用首次打开的注意力：人在弄清产品是什么之前就被要求做不可逆的隐私决定，默认策略变成一律拒绝或一律点允许，两者都不是知情选择。
怎么研究
比较「安装或首次启动时列出全部权限」与「进入对应功能时才出现系统弹窗」，测量授权与事后理解，而不是只看允许率。
自变量：请求相对首次启动的延迟、请求是否紧挨可观察的功能动作、同时出现的权限个数。 因变量：允许/拒绝、事后能否复述该权限支持哪项功能、首次会话完成率、事后惊讶（「原来它一直在用这个」）。
实验室里被试知道这是权限实验，会异常认真读弹窗；真实安装漏斗里启动时的弹窗常被当成障碍物关掉。不要把「启动时允许率低」直接读成「文案写得差」——时机本身在改变人用来评价必要性的参照。
边界
操作系统仍要求某些能力在后台启动前就授予（开机自启类的企业设备管理、无界面配件连接），即时请求没有落点。纯工具应用一打开就是拍照或录音，启动即使用，启动请求与即时请求重合。儿童账户或被管理设备上，权限由家长或管理员预置，终端用户并不做这次决定。
怎么落地
- 把每条权限绑定到一个可点击的功能入口；没有该入口被激活，就不要触发系统弹窗。
- 从启动、注册、空状态里删掉权限请求；需要能力才能演示时，先用无需权限的示例内容撑起第一屏。
- 一次只请求当前动作所需的那一项，下一项等下一个动作。
- 验证：录制首次会话，标出每个系统权限弹窗出现的前一个用户动作；若前一个动作不是「使用该能力」，时机就失败。再比「启动时请求」与「功能内请求」在同一流量窗口的允许率与任务完成率。