allow属性必须明确指定来源，格式为feature=(source)，否则API调用失败；空格分隔已废弃，须用分号；microphone=()是最稳妥的禁用方式；策略仅作用于当前iframe且需HTTP(S)环境生效。
allow属性不写来源列表，API调用直接失败
省略来源或只写特性名（如allow="geolocation"）等同于禁用该功能。浏览器不会弹窗请求授权，navigator.geolocation.getCurrentPosition()会立刻抛出NotAllowedError。这不是bug，而是默认安全策略：没明确说“谁可以”，就一律不放行。
必须为每个特性指定来源，格式是feature=(source)，括号不能少，等号不能漏。常见错误包括：
-
allow="microphone 'self'"→ 缺等号和括号，Chrome 100+ 完全忽略整条 -
allow="clipboard-read https://a.com"→ 旧语法，空格分隔已废弃 -
allow="fullscreen"→ 没来源，document.documentElement.requestFullscreen()静默失败
多个权限必须用分号分隔，不能用空格或逗号
Chrome 100+（2026年主流版本）已彻底弃用空格分隔的旧写法。写成allow="geolocation clipboard-read"会被当成一个无效特性名，整个allow值失效，等价于没写。
正确写法是严格用分号+空格（空格可选但建议保留可读性）：
立即学习“前端免费学习笔记（深入）”；
<iframe src="https://thirdparty.example/embed" allow="geolocation='self'; clipboard-read='self'; microphone=()"></iframe>
注意：'self'指 iframe 自身的源（协议+域名+端口），不是父页面源；()表示显式禁止，比省略更可靠；*允许所有来源，对microphone或camera慎用。
microphone=() 是禁用麦克风最稳妥的方式
想彻底阻止第三方组件调用getUserMedia({ audio: true })，唯一可靠写法是microphone=()。它优先级高于HTTP响应头中的Permissions-Policy，且浏览器执行时不会尝试弹窗、不会静默采集，直接报错。
其他写法风险高：
-
microphone='none'→ Feature Policy 旧语法，现代浏览器直接跳过 -
microphone（无来源）→ 默认拒绝，但行为不如=()明确 -
microphone='*'→ 允许任意来源，隐私失控，Chrome 已在部分场景静默降级为'self'
验证是否生效：在 DevTools Console 切换到该 iframe 上下文，运行navigator.permissions.query({ name: 'microphone' }).then(r => console.log(r.state))，返回"denied"说明策略已起作用。
allow只控制iframe内部，不影响父页面或其他iframe
allow属性的作用域非常明确：仅对该<iframe>标签及其子浏览上下文（比如它里面再嵌套的 iframe）生效。父页面的脚本、样式、权限状态完全不受影响。
这意味着：
- 你不能靠父页面的
allow去限制子 iframe 里再嵌的 iframe —— 必须在每一层 iframe 标签上单独写 - 父页面仍需通过 HTTP 响应头（如
Permissions-Policy: camera=()）或 meta 标签（兼容性差）管控自身权限 - 跨域 iframe 无法读取父页面 DOM，但能用自己的源申请权限，所以
'self'始终指向它自己的 origin
最容易被忽略的一点：本地开发时用file://协议打开 HTML，所有allow策略都不生效。必须走 HTTP(S) 服务才能测试真实行为。
