H4.10.3permission status–availability mismatch设计
权限状态显示与功能实际可用性脱节会让用户误判故障原因
别名: 状态与可用性脱节 · 假开启 · stale permission UI · false granted state
概念解释
应用内写着「位置已开启」「通知已允许」，功能却不能定位、收不到通知——或者反过来，功能明明可用，开关画成关闭。状态展示与实际可用性脱节时，人会把原因判成网络故障、账号坏了、应用需要重装，而不是去改权限。这条谈的是展示与事实必须一致，不是系统里撤权后要不要检测（检测是为了让事实更新），也不是使用中圆点与设置行如何分工。
机制
人用开关位置当诊断：开着却不能用，就在开关以外的系统上找错。常见来源有三种：本地缓存未刷新；应用内开关只控业务偏好、却画成系统权限；系统是「仅本次 / 选中的照片」而界面画成「全部允许」。错因一旦外推，修复动作也错：开关网络、清缓存、重装，权限仍停在原处。脱节还会反向伤害信任：功能能用但显示未开启时，人以为产品在未授权采集。
边界
系统权限已开、但业务侧另有「暂停通知」类偏好时，必须画成两层：系统授权一行、业务偏好一行，不能合成一个会撒谎的开关。权限已开而硬件不可用（飞行模式关定位、摄像头被占用）应报硬件或占用，不要把权限行改成关闭。延迟一两秒的刷新可以接受，持续显示过期状态不行。
怎么落地
- 权限行的文案只反映系统授权枚举值（允许 / 拒绝 / 仅本次 / 选中项目 / 未决定），业务偏好用另一行。
- 功能入口的可用态与该枚举值绑定：系统拒绝时入口走降级，不得仍显示「已开启」的成功态。
- 从系统设置返回应用的那一次生命周期，必须重读并重绘，禁止沿用进入设置前的截图式状态。
- 验证：构造四种组合——系统开/关 × 界面开/关，找未参与设计的人看界面并预测「现在能不能用、坏了该去哪」。预测与真实可用性不一致，或去了错误的修复处（网络、重装），展示失败。