APP首次打开就连续请求定位、相机、相册、通知和通讯录，用户很难判断每一项的必要性，最自然的反应就是全部拒绝。系统弹窗机会有限，一旦拒绝，后续恢复成本更高。
权限设计不是把合规文案写长，而是让申请与当前任务产生因果：用户知道自己要做什么，也知道为什么需要这项能力。
01 在功能触发时申请，而不是“先拿再说”
扫码时申请相机、查附近门店时申请定位、上传头像时申请相册，比首页统一弹窗更容易理解。
如果没有权限也能完成任务，应提供手动输入、选择城市、上传文件等替代方式。
02 系统弹窗前的解释要短且具体
前置页面说明“用于什么、何时使用、是否持续收集”，并让用户主动点击继续。不要使用“为了提供更好体验”这种泛化理由。
解释页面不能伪装成系统弹窗，也不要用恐吓或默认勾选迫使同意。
常见权限的合理触发场景
| 权限 | 合理时机 | 可替代方式 | 高风险做法 |
|---|---|---|---|
| 相机 | 用户点击扫码、拍摄、识别 | 手动输入、从相册选择 | 首次打开就申请 |
| 定位 | 查看附近、导航、配送地址 | 手动选择城市或地址 | 后台持续定位却不说明 |
| 通知 | 用户完成关键体验后订阅提醒 | 站内消息、邮件 | 注册后立刻弹出 |
| 相册/文件 | 上传头像、凭证或附件 | 拍摄或其他文件入口 | 读取全部相册无必要 |
| 麦克风 | 开始录音、语音输入或通话 | 文字输入 | 仅为“以后可能用”提前申请 |
03 申请范围遵循最小必要
只申请当前功能所需的范围和时长。可以选择单张照片，就不要要求访问全部相册；只在使用期间需要定位，就不要默认持续后台定位。
权限和数据收集不是同一回事。获得系统权限后，仍需清楚说明数据用途、保存和共享。
04 拒绝不是死路
用户拒绝后先解释受影响功能，提供不授权的替代路径。只有再次主动使用该功能时，再提示前往设置。
不要每次进入页面都重复弹出自定义弹窗，也不要让拒绝导致整个APP无法使用，除非它确实是核心且不可替代。
05 不同平台与版本要分别验证
iOS和Android的权限类型、系统文案和设置路径不同，系统升级也可能变化。设计稿应标明平台差异，开发使用当前官方API。
隐私说明、商店信息和实际请求要一致，避免审核和信任问题。
06 通过权限漏斗定位问题
记录触发功能、解释页展示、系统弹窗、允许、拒绝、设置恢复和任务完成。不要只看最终授权率。
如果授权低，先检查时机和价值是否清楚；如果授权高但功能使用低，可能是过度申请。
常见问题
通知权限什么时候申请最好？
通常在用户体验到价值、设置了需要提醒的任务或主动开启提醒时，比首次启动立即申请更合适。
拒绝后可以再次弹系统权限吗？
平台规则不同，很多情况下需要引导到系统设置。应避免频繁打扰，并提供替代。
定位权限必须选“始终允许”吗？
多数功能只需使用期间授权。只有确实依赖后台定位的场景才提出更高权限，并明确说明。
前置说明页需要很长的隐私文本吗？
不需要。前置说明解决当前权限用途，完整数据处理放在隐私政策中，两者都要准确。
权限申请属于设计还是开发工作？
需要产品、设计、开发和法务共同确认。设计负责场景与解释，开发负责API与状态，法务核对用途和披露。
链接复制成功
