HTML本身不支持第三方应用权限细化，真正起作用的是浏览器的Permissions API、iframe的allow属性及sandbox策略，权限请求必须由JavaScript主动触发，HTML仅能通过allow属性控制嵌入资源的功能开关。
HTML 本身不支持第三方应用权限细化
HTML 是标记语言，没有运行时权限模型，iframe 或 script 标签引入的第三方资源，浏览器根本不会让 HTML 自己决定“只给它访问摄像头但不给麦克风”这种粒度的授权。
真正起作用的是浏览器的权限 API（如 Permissions API）和嵌入上下文的安全策略（如 sandbox 属性、allow 属性），它们由 JavaScript 调用或 iframe 的 HTML 属性控制，不是 HTML 文档结构本身的能力。
iframe 的 allow 属性是功能开关的实际落点
如果你在页面里用 iframe 嵌入第三方应用（比如视频会议 widget、支付弹窗），能做的最接近“按功能开关授权”的操作，就是配 allow 属性：
-
allow="geolocation"→ 允许获取位置，不写就不行 -
allow="camera;microphone"→ 明确放行音视频，缺一不可 -
allow="clipboard-read;clipboard-write"→ 控制剪贴板访问 -
allow="fullscreen"→ 决定能否全屏，对很多工具很关键
注意：allow 只对同源或 CORS 配合得当的跨域 iframe 生效；如果第三方没主动调用 navigator.permissions.request()，写了也没用——它只是“开了门”，对方还得自己“伸手要”。
立即学习“前端免费学习笔记（深入）”；
权限请求必须由 JavaScript 主动触发，HTML 不会自动弹窗
用户看到的“是否允许使用摄像头”弹窗，永远来自 JS 调用，例如：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
await navigator.mediaDevices.getUserMedia({ video: true, audio: false });
这个调用会触发浏览器检查 iframe 的 allow 属性、当前页面协议（必须是 https 或 localhost）、用户历史选择，再决定是否弹窗。HTML 里写再多 <meta> 或注释都无济于事。
常见错误现象：
- 页面加载就报错
NotAllowedError: Permission denied→ 实际是 JS 在没用户交互（如 click）的情况下提前调了getUserMedia - 写了
allow="camera"但依然被拒 → 第三方脚本运行在沙箱环境（sandbox属性没包含allow-scripts）或缺少allow-same-origin（影响权限继承） - 移动端 Chrome 不弹窗 → 没加
playsinline属性导致媒体自动播放被拦，连带权限请求被抑制
真正可控的只有嵌入边界，不是“授权逻辑”
所谓“权限细化”，在 HTML 层能做到的极限就是：
- 用
iframe sandbox="allow-scripts allow-popups"关死默认能力，再用allow="..."逐个开闸 - 配合
referrerpolicy="no-referrer"和loading="lazy"减少第三方无意收集的信息面 - 用
CSP（Content-Security-Policy HTTP 头）限制第三方脚本能连接哪些域名、执行哪些内联代码——这比 HTML 标签更底层、更有效
别指望靠改几个 HTML 属性就实现 OAuth 那种 scope 级别的授权。那属于后端鉴权流程，HTML 连 session 都存不了。
最容易被忽略的一点：即使你把 allow 写得再细，只要第三方脚本本身没做权限降级处理（比如检测到没获 microphone 就自动禁用语音按钮），用户仍可能看到灰掉的功能入口——HTML 控制不了它的 UI 响应逻辑。
