Permissions-Policy（原Feature Policy）是声明式策略，通过HTTP响应头或iframe的allow属性在资源加载前限制API访问；allow属性仅作用于该iframe及其子上下文，权限需显式指定来源并用分号分隔，空格分隔已废弃，且不控制父页面行为。
Feature Policy 已更名为 Permissions-Policy，它不是在 DOM 层级“动态拦截”API 调用的运行时钩子，而是通过声明式策略，在浏览器加载资源前就限制特定功能的可用性。所谓“DOM 层级强制限制”，实际是指在 HTML 元素（尤其是 <iframe>）上下文中，以最小侵入方式约束其内嵌内容对敏感 API 的访问能力——不依赖 JS 检查，也不修改 DOM 结构，而靠浏览器原生解析与执行策略。
用 iframe 的 allow 属性做最直接的控制
这是唯一能在 HTML 标签层面生效、且优先级高于 HTTP 响应头的方式。它只作用于该 iframe 及其子浏览上下文，不影响父页面。
- 每个权限必须显式列出来源，用括号包裹，例如
geolocation 'self' https://maps.example.com - 多个权限用分号
;分隔，空格或逗号会失效 -
()表示明确禁止（比省略更可靠），*表示允许所有来源（慎用，尤其对microphone或camera） -
'self'指 iframe 自身的源，不是父页面源；跨域 iframe 无法读取父页面 DOM，但能用自己的源申请权限
避免常见配置翻车点
很多“权限没生效”其实源于语法错误或理解偏差，而非策略本身无效。
- 写成
allow="geolocation"→ 缺少来源列表，浏览器按默认策略拒绝，调用navigator.geolocation.getCurrentPosition()直接抛NotAllowedError - 用空格分隔多个指令，如
allow="geolocation clipboard-read"→ Chrome 100+ 已废弃旧语法，必须改用分号：allow="geolocation 'self'; clipboard-read 'self' - 误以为
allow能控制父页面行为 → 它只约束 iframe 内部脚本，父页面仍需单独通过响应头或 meta 标签管控自身权限
配合 navigator.permissions.query() 做合理降级
该 API 返回的 state: "prompt" 不代表可立即调用对应 API，仅表示“尚未拒绝”。真正调用仍需满足两个硬条件：
- 用户手势触发（如点击、触摸），不能在页面加载时自动执行
- 所在 iframe 已通过
allow获得该权限授权（否则 query 返回denied或直接报错） - 即使 query 返回
granted，也建议包裹 try/catch，因部分设备或策略可能临时禁用硬件支持
不推荐在 <meta> 中设置 Permissions-Policy
虽然规范允许用 <meta http-equiv="Permissions-Policy" content="...">，但实际兼容性差：
- Chrome 和 Edge 支持有限，Firefox 完全不支持 meta 方式
- 无法为不同 iframe 设置差异化策略（meta 是全局作用于整个文档）
- 服务端响应头或 iframe allow 属性才是稳定、可维护的选择
