allow属性控制iframe可调用的浏览器API，如camera、microphone、geolocation、clipboard-read/write、fullscreen、payment等，是原生HTML属性，不依赖CSP或sandbox，但需与之协同；值格式为"feature 'self'; feature https://example.com"，来源限制对部分特性生效，省略则默认禁用多数敏感API。
allow 属性控制哪些浏览器 API 可被 iframe 调用
allow 是 iframe 的原生 HTML 属性，不依赖 CSP 或 sandbox，但它直接决定子页面能否调用特定浏览器 API。比如写了 allow="geolocation"，但子页面调用 navigator.geolocation.getCurrentPosition() 仍会抛出 NotAllowedError——不是代码写错了，而是用户没点授权弹窗，或者页面没获得焦点。
它管控的不是脚本执行权，而是「功能开关」：camera、microphone、clipboard-read、clipboard-write、fullscreen、payment、accelerometer、gyroscope 等都归它管。这些特性原本属于 Feature Policy，现在已被 Permissions-Policy HTTP 头取代，但 allow 在 iframe 上依然完全有效，且所有主流浏览器（Chrome 84+、Firefox 82+、Safari 16.4+）都支持。
- 没写
allow或写成allow=""，等价于全部禁用——这是浏览器默认安全策略，不是 bug -
allow="fullscreen"这类不涉及跨源数据的特性，来源限制会被忽略 -
allow="clipboard-write *"在 Chrome 95+ 会被静默降级为clipboard-write 'self'，第三方域名实际无法写入
allow 值的格式必须匹配使用场景
allow 的值是字符串，语法为 "feature1 'self'; feature2 https://a.com https://b.com"，多个策略用分号分隔，每个策略后可跟来源列表。来源只对部分特性生效（如 clipboard-read、payment），而 autoplay、fullscreen 不校验来源。
常见写法：
-
'self'：仅允许同源（协议+域名+端口完全一致）子页面启用该功能 -
https://trusted.example.com：精确指定一个或多个域名，空格分隔 -
'none'：显式禁用某特性，例如allow="microphone 'none'" -
*：理论上允许所有来源，但多数敏感特性（如microphone）在现代浏览器中已默认拒绝，即使写了也无效
错误示例：allow="clipboard-write *" 看似放开权限，实则 Chrome 会自动收紧；allow="geolocation https://example.com" 若子页面来自 https://sub.example.com，也会失败——子域名不算同源，必须写全。
和 sandbox、Permissions-Policy 如何协同
sandbox 和 allow 解决不同层面的问题：sandbox 控制脚本执行、表单提交、插件加载等基础能力；allow 则在 sandbox 放开的前提下，进一步声明「哪些高级 API 可用」。两者不互斥，常一起用：
<iframe src="https://widget.example.com" sandbox="allow-scripts allow-same-origin" allow="clipboard-read 'self'; payment https://pay.example.com"></iframe>
注意：sandbox 若没加 allow-same-origin，'self' 就失效；若用了 sandbox 但没开 allow-scripts，那 allow 再宽也没用——子页面根本跑不了 JS。
HTTP 响应头 Permissions-Policy 作用范围更广（整个页面或响应域），而 allow 只作用于当前 iframe。当两者冲突时，更严格的策略胜出。比如响应头设了 geolocation=()（禁止所有来源），iframe 却写了 allow="geolocation"，最终仍不可用。
容易被忽略的兼容性与调试细节
很多问题不是配置错，而是时机或上下文不对：
-
clipboard-write要求页面有焦点且由用户手势触发（如 click、keydown），单纯 onload 里调用必失败 -
autoplay必须配合muted属性，否则即使写了allow="autoplay"也会被静音拦截 - 移动端 Safari 对
microphone和camera的allow声明支持较晚（iOS 16.4+），旧版本直接忽略 - 调试时看控制台报错类型：
NotAllowedError是权限拒绝，SecurityError是上下文不合法（如非 secure context 下调用），DOMException: Document is not focused是焦点缺失——每种对应不同修复路径
真正麻烦的不是怎么写 allow，而是确认子页面是否满足所有前置条件：HTTPS、用户手势、焦点状态、父页面是否被 sandbox 限制过严、以及目标浏览器是否真正支持该特性组合。
