Permissions API 能做什么？浏览器权限设计有哪些注意点？

简化版

Permissions API 可以查询部分浏览器能力的授权状态，例如地理位置、通知、摄像头等是否 granted、denied 或 prompt。权限设计要在用户明确需要时请求，说明用途，处理拒绝和降级，并避免过度索权。

详细版

常见权限能力：

地理位置。
通知。
摄像头和麦克风。
剪贴板。
MIDI、传感器等特殊能力。

设计要点：

先解释价值，再触发浏览器权限请求。
不要首页一次性索取全部权限。
拒绝后提供手动输入或其他路径。
权限状态可能变化，不能永久缓存。
不同浏览器支持和行为不同。

Permissions API 可帮助优化提示时机，但不能替代真正的权限请求。

完整版教学

一、权限是用户信任边界

浏览器权限保护的是摄像头、定位、通知、剪贴板等敏感能力。网页如果能随便访问这些能力，隐私风险会非常大。因此浏览器要求用户授权，并且越来越强调安全上下文和明确意图。

权限设计的重点不是“怎么弹框”，而是让用户理解为什么需要这个权限。如果用户觉得你过度索权，即使功能合法，也会拒绝甚至离开。

用户意图 → 页面解释 → 浏览器授权 → 使用能力 → 提供拒绝兜底

二、Permissions API 查询的是状态

Permissions API 可以查询某些权限当前状态：granted 已授权，denied 已拒绝，prompt 需要询问。它让页面在真正调用能力前了解大致状态，从而选择合适 UI。

const result = await navigator.permissions.query({ name: 'geolocation' })
console.log(result.state) // granted | denied | prompt

result.onchange = () => {
  console.log('permission changed:', result.state)
}

但不是所有权限和浏览器都支持同样查询。代码要做特性检测，不能因为查询失败就让功能崩溃。

三、授权时机决定通过率

首页刚打开就请求通知、定位、摄像头，用户会很警惕。更好的时机是用户点击“查附近门店”时请求定位，点击“开启直播”时请求摄像头，点击“订阅更新”时请求通知。

数字例子：无上下文弹通知授权，通过率可能只有 5%；用户点击“降价提醒”后再请求，可能提升到 30%。同样的技术 API，时机不同，授权结果差距很大。

权限	差时机	好时机
定位	打开首页	查看附近服务
通知	首屏弹窗	用户订阅提醒
摄像头	进入站点	点击扫码/拍照
麦克风	页面加载	点击录音

四、拒绝授权不是异常

用户拒绝权限是正常选择，不应该让主流程直接崩溃。附近门店可以手动选择城市，通知提醒可以改为站内提醒，摄像头扫码可以输入码。拒绝后反复弹权限说明会让体验更差。

浏览器层拒绝后，有些权限不能再次直接弹出，只能引导用户去设置中开启。因此页面要记住交互策略：解释、请求、拒绝后给路径，而不是无限请求。

五、权限状态可能变化

用户可以在浏览器设置里撤销权限，也可能因隐私模式、系统设置、设备变化导致能力不可用。应用不能永久缓存“用户已授权”。每次使用敏感能力前，都应能处理失败。

例如昨天摄像头授权成功，今天用户系统层禁用了摄像头，调用仍可能失败。权限状态只是参考，真正调用能力时仍要捕获错误。

六、隐私最小化比拿到权限更重要

拿到权限不代表可以无限使用。定位只用于附近门店时，不要持续后台定位；摄像头只用于拍照时，不要长时间保持流；通知只用于用户订阅的事项，不要滥发营销。

数据也要最小化。只需要城市就不要上传精确经纬度，只需要一次头像就不要持续采集视频。权限和数据采集都应围绕明确目的。

权限心法：先让用户知道价值，再请求最小权限；拒绝也能走，授权也别滥用。

七、常见误区与追问

误区：Permissions API 可以直接弹授权。 它主要查询权限状态，真正请求通常由具体能力 API 触发。
误区：首页把所有权限一次性要完更省事。 无上下文索权会降低信任和授权率。
误区：用户拒绝就是错误。 拒绝是正常分支，应提供降级路径。
追问：权限状态有哪些？ 常见是 granted、denied、prompt，具体支持因浏览器而异。
追问：为什么已授权调用仍失败？ 可能系统权限关闭、设备不可用、浏览器策略变化或运行环境限制。
追问：如何提升授权率？ 在用户明确触发相关功能时解释用途，再请求权限。

八、加强记忆

Permissions API 用“查状态、不强求、按需请、拒绝兜底”来记。它帮助你了解授权状态，但真正能力调用仍会失败；权限设计要围绕用户意图和隐私最小化，别把弹窗当流程开始，把信任当成可以消耗的资源。

简化版

详细版