批量请求会降低整体通过率
别名: 批量权限 · 权限堆叠 · permission bundling · shotgun permission
概念解释
批量请求指在同一决策窗口里连续或同时抛出多项系统权限：启动后先位置、再通知、再通讯录，或一张清单上要求全部勾选。人面对的不是「要不要给这项能力」，而是「要不要现在处理一叠授权」。整体通过率——每项权限最终被允许的比例——通常低于把同一组权限拆到各自功能上分别问。这条只谈多项请求挤在同一时机的代价，不谈单次请求该不该等功能发生，也不谈通知要不要按类别订阅。
机制
多项授权共享同一次注意力与同一次风险预算。人会用最敏感的那一项给整叠定价：通讯录看起来比相机可怕，于是相机也被拒。连续弹窗还会触发习惯化——第一张还读，第二张开始点「不允许」以求结束。批量也切断了「这项权限对应哪个动作」的映射，人无法逐项检验必要性，只能整包接受或整包拒绝。通过率下降往往不是每一项都变得更不可信，而是决策从「评价用途」退化成「结束打断」。
怎么研究
把同一组权限做成「一次列出 / 连续弹出」与「按功能分散在会话中」，比较各项的最终授权状态。
自变量：同屏或同会话内的请求个数、顺序（敏感项在前或在后）、两项之间是否插入真实任务。 因变量：各项允许率、整包拒绝率、第一项之后的阅读时间衰减、事后能否配对「权限—功能」。
允许率会把「读完后拒绝」和「为了关掉下一张而拒绝」混在一起，需要眼动、阅读时长或事后解释把两者拆开。不要把「最后一项允许率低」读成该项本身敏感——顺序位置本身会制造下降。实验室一次塞完所有弹窗，会高估真实产品里分散请求的耐心。
边界
成套硬件能力必须同时具备才能启动（视频通话要相机加麦克风），拆开请求会让人允许了第一项却在第二项失败，任务仍然做不成；这时应在进入通话前短间隔内问齐，但仍应逐项出现而不是合成一个假的「媒体权限」。企业移动管理用一纸协议授权整组能力，终端上不再出现分项弹窗。无障碍或车机等注意力极短的情境里，连续弹窗的危害大于桌面，更不能批量。
怎么落地
- 列出每条权限的触发动作，禁止两个动作尚未发生就把两条权限排进同一队列。
- 必须成套才能工作的能力，在进入该任务的前几秒内逐项请求，中间用一句「还需要麦克风才能让对方听见」连接，不要合成一张多选清单。
- 敏感项不要当队列的第一张；若它不是当前动作所需，挪到真正用到通讯录或精确位置的时候。
- 验证：按权限画允许漏斗，看第二项起是否出现与内容无关的陡降；把队列拆开后，同一流量窗口里各项允许率应分别回升，而不是只看「至少允许了一项」的合计。