HTML不参与权限控制，仅能以文本形式准确展示OAuth实际请求的scope范围，所有真实权限均由JavaScript调用浏览器API或服务端OAuth流程决定。
HTML里根本没有“授权范围”或“权限列表”这个概念
浏览器不会因为你在 HTML 里写了某段文字，就自动授予页面访问摄像头、位置或通知的权限。所谓“第三方授权范围说明”，实际是前端配合后端 OAuth 流程时，在用户点击授权前展示的一份静态提示——它不参与真实鉴权，也不被浏览器解析为权限声明。
常见错误现象：Permission denied 报错却在 HTML 里反复修改 <meta> 或自定义属性；把 scope=profile+email 直接塞进 <a href></a> 当作生效依据。
- 真实权限由 JavaScript 调用
navigator.permissions.query()或触发navigator.mediaDevices.getUserMedia()等 API 后，由浏览器弹窗决定 - OAuth 的
scope参数必须传给认证服务器（如 GitHub / Google 的/oauth/authorize接口），不是 HTML 标签能控制的 - HTML 唯一能做的，只是用普通文本或
<dl></dl>列出将要请求的权限项，供用户阅读——它和权限获取过程完全解耦
怎么在页面上安全、准确地展示授权范围说明
核心原则：用语明确、与后端实际请求的 scope 严格一致，避免让用户产生“已授权”错觉。
使用场景：OAuth 登录按钮旁的辅助文案、隐私弹窗中的第二屏说明、设置页的连接服务详情。
立即学习“前端免费学习笔记（深入）”；
- 不要写“我们将获取您的头像”，而应写“登录后，本应用将通过 GitHub 请求您的公开资料（
user:email,user:public_repo）” - 如果后端请求的是
https://www.googleapis.com/auth/userinfo.email，HTML 里就照写，别简化成“邮箱权限” - 避免使用
<input type="checkbox">模拟授权同意——这容易误导用户以为勾选即完成授权，实际仍需跳转 OAuth 流程
为什么不能用 manifest.json 或 permissions 属性代替说明
有人试图在 PWA 的 manifest.json 里加 "permissions": ["geolocation"]，或给 加 permissions="geolocation" —— 这些写法既无效，也不被任何浏览器支持。
性能 / 兼容性影响：这些非法属性会被浏览器忽略，但可能干扰自动化测试工具对页面语义的解析；某些老旧爬虫会误判为结构化数据错误。
-
manifest.json中的permissions字段根本不存在于 Web App Manifest 规范中（只有webapp类型的 Chrome App 才有，且已废弃） - HTML 全局属性里没有
permissions，加了等于白加，还可能被 Lighthouse 标记为“无效属性” - 真正需要声明权限的地方是服务端 OAuth 请求 URL 的
scope参数，例如：https://github.com/login/oauth/authorize?scope=user%3Aemail%2Cread%3Aorg
用户点了“同意”之后，HTML 还能做什么
HTML 本身无法响应授权结果，但可以配合 JS 做轻量级状态提示。关键点在于：不要假装控制流程，只做信息同步。
常见错误现象：在回调页（如 /auth/callback）里用纯 HTML 显示“授权成功”，却不检查 URL 中的 code 参数是否真实存在；或把 access_token 拼在 HTML 注释里企图“透传”。
- 回调页应优先用 JS 读取 URL search 参数，验证
code和state是否匹配，再决定是否显示欢迎语 - 可借助
<meta name="oauth-state" content="abc123">在重定向前缓存临时状态，但绝不存敏感 token - 如果后端返回了用户基础信息（如
login、avatar_url），可用 JS 注入到 HTML 预留的<span id="user-name"></span>中，而非服务端渲染整页
