权限治理与跨浏览器兼容

• DNR 与阻塞式 webRequest 的合规差异
• 企业策略（policy）允许的阻塞式 webRequest
• 面向企业 vs 面向公众的扩展能力差异

面向普通用户的 MV3 扩展只能使用 declarativeNetRequest（声明式）做请求拦截/改写，阻塞式 webRequest 已被移除，以保护隐私与性能。但通过 Chrome 企业策略（ExtensionSettings/policy 安装的受控扩展）安装的扩展仍可使用部分阻塞式 webRequest API，这是企业环境的合规延伸。因此同一扩展需要根据"是否由企业策略安装"做好能力检测与降级，在公共环境用 DNR、在企业环境用 webRequest。

合规边界是"按用户环境区分能力"。工程上应检测扩展是否处于企业受控环境（chrome.management 或策略标志），据此选择拦截实现，并保证两种路径都可用。

• 强制权限 vs 可选权限的边界
• optional_permissions 与 optional_host_permissions 的按需申请
• 权限拒绝后的功能降级

强制权限（permissions/host_permissions）在安装时整体授予，无法逐项延后；可选权限（optional_permissions/optional_host_permissions）可用 chrome.permissions.request 在运行时按用户手势申请，实现"按需授权延后"。工程边界：把核心必需能力放强制权限（保证基础功能），把可有可无或较强侵入的能力放 optional，在用户实际触发时申请；申请被拒后要优雅降级（如禁用相关功能并提示），并监听 chrome.permissions.onRemoved 处理权限被撤销。

权限延后的关键是"分等级设计权限部署"。既保证安装转化率，又满足功能与合规，关键是处理好强制/可选/拒绝/撤销四个状态。

• extension_pages 的 CSP 配置
• 禁止内联脚本与 eval 的意义
• 与前端构建工具的配合

MV3 中 manifest 的 content_security_policy.extension_pages 定义扩展页面的 CSP，默认禁止内联脚本、eval 与远程代码，仅允许 'self' 即扩展自身资源。这从机制上切断了 XSS 注入内联恶意脚本与 eval 动态执行代码的路径。工程注意点：前端框架（如 Vue/React 加内联样式）需打包为本地文件，避免使用 -unsafe-inline 或 -unsafe-eval；弹窗/面板用打包产物，确保所有脚本来自扩展自身。

CSP 是扩展页面的安全防线。工程上应保持严格、不放松，用打包 + 静态资源替代动态脚本，从而把风险降到最低。

• externally_connectable 的 matches 与 ids 配置
• 来源验证的机制与价值
• 防止恶意来源注入消息

externally_connectable 在 manifest 中声明允许与本扩展通信的 Web 源（matches）与扩展 ID（ids），只有白名单内的来源才能通过 chrome.runtime.sendMessage/connect 激活扩展的 onMessageExternal/onConnectExternal。这是来源验证的安全门槛：防止任意网页或扩展向你的扩展注入消息、触发危险操作。工程上应精确配置白名单，并在接收端校验 event.sender 信息，双重确认。

来源验证是"谁可以进"的门禁。工程价值在于把外部消息交互限制在可信范围，阻断恶意网页/扩展的跨上下文攻击。配置越窄越安全。

• content_scripts 的 matches 与 host_permissions 的关系
• all_frames 控制 iframe 注入
• run_at 控制注入时机

content_scripts 的 matches 决定注入哪些 URL，但扩展通常还需对应的 host_permissions 才能访问这些站点（某些场景下仅声明 content_scripts 即可注入，但读取网络/存储等需 host 权限）。all_frames 控制是否注入到 iframe（false 只注入顶层 frame），run_at 控制注入时机（document_start/idle/end）。工程上通过精确的 matches、限制 all_frames、合理 run_at 来治理作用域，减少不必要注入与冲突。

作用域治理是"控制脚本在哪些页面、哪些 frame、何时运行"。三者配合能最小化注入面、降低性能与安全隐患，也便于满足审核。

• GA4 用于扩展遥测的注意点
• Privacy Sandbox 对第三方跟踪的约束
• GDPR 同意与数据最小化

扩展用 GA4 收集遥测时，需注意：数据最小化、提供用户同意/退出机制、不收集敏感浏览数据；GA4 作为第三方 cookie 依赖在扩展场景下受限，且 Privacy Sandbox 限制跨站跟踪，扩展不应借机规避。GDPR 合规要点：明确告知数据处理目的、提供隐私政策与 opt-out、数据匿名化、遵守数据保留期限。工程上把遥测做成默认关闭的 opt-in，并存储同意状态。

在 Privacy Sandbox 与 GDPR 双重约束下，扩展遥测必须"透明 + 可控 + 最小化"。合规是扩展上架与长期运营的前提，应在架构上内建同意机制。

• build-time manifest 生成（按浏览器目标）
• 自动化 MV2→MV3 迁移
• 模板与配置驱动的构建

跨浏览器构建用构建脚本（Node/Webpack plugin）在 build 阶段根据目标浏览器生成不同 manifest.json（如 Chrome 用 action、Firefox 用 browser_action/background.scripts、Safari 用额外字段），实现条件编译。自动化 MV2→MV3 迁移可用工具/脚本把 background 页改为 service_worker、把 webRequest 改为 DNR、移除远程代码、更新 WAR 配置，在 CI 中做 manifest 校验与双版本构建。这样一套代码可产出多浏览器、多版本产物。

构建期配置化是跨浏览器扩展的核心工程实践。把差异收敛到 manifest 模板，配合自动化迁移脚本，可显著降低维护成本与版本漂移风险。

• Permissions-Policy 头部与 iframe allow 属性
• 能力委托（geolocation、camera 等）
• 对扩展页面与嵌入 iframe 的影响

Permissions-Policy（HTTP 头或

Permissions Policy 是"能力按 iframe 委托"的机制。扩展嵌入内容时需确保必要的 allow 属性，否则目标能力不可用。这是 Web 权限模型的一部分，与扩展自身权限并行。

• ExtensionInstallForcelist 强制安装
• ExtensionSettings 细粒度控制
• managed storage 下发只读配置

ExtensionInstallForcelist 指定扩展 ID 与更新源，实现强制静默安装（用户无法卸载）；ExtensionSettings 提供扩展级策略（安装来源白名单、权限控制、更新 URL 等）。配合 managed storage（chrome.storage.managed），企业策略可向下发只读配置（如 API 域名、功能开关、合规设置），扩展读取该配置自适应企业环境。这一组合让企业能够无感部署、集中管控并统一配置。

企业分发是"策略强制 + 配置下发"。扩展需主动读取 managed storage 并监听策略变化，实现企业级可管理性，这是 toB 扩展的硬需求。

• Group Policy 中配置扩展策略
• 内网 update_url 与 CRX 分发
• 域控环境的静默部署

企业通过 AD 域控（Group Policy）在受管 Chromium/Edge 上配置 ExtensionInstallForcelist 与 ExtensionSettings 策略，实现域内批量静默安装。内网部署时将扩展包与 update_url 指向内网服务器（配置 XML 更新清单），配合策略指定内网地址，让扩展在无外网环境也能更新。注意点：策略需在目标机器生效、证书与签名校验、更新清单格式正确、以及内网 URL 的可用性。

域控分发是"受管设备批量部署"的经典路径。工程上要保证扩展包可离线安装、更新源可自托管，并支持通过策略读取环境配置。

• Firefox MV3 的差异与兼容
• Safari Web Extension 的转换流程
• xcrun safari-web-extension-converter 工具

Firefox 的 MV3 与 Chrome 存在差异（如持久化 background、webRequest 支持更宽），需用 polyfill 与构建期适配。Safari 通过 Xcode 的 xcrun safari-web-extension-converter 把 Chrome 扩展转换为 Safari Web Extension：它会生成 Xcode 工程与 Safari 扩展包，并处理 manifest 差异（Safari 无完全等同的 MV3 特性，需手动调整 API 差异）。限制：Safari 对部分 API（如 declarativeNetRequest 的细节、offscreen document）支持不同，需在转换后手动修复。

跨浏览器转换不能"一键完成"，需在转换后再做 API 级适配与测试。工程上应尽量减少对某个浏览器专用 API 的依赖，维护统一的兼容层。

• 远程代码（远程加载脚本）被拒
• 权限过度申请
• 审核准备与自查

常见被拒原因：1) 远程代码——从远程下载/执行脚本（违反 MV3 禁止远程代码）；2) 权限过度申请——声明了与功能无关或过宽的权限；3) 误导性描述/功能；4) 隐私数据收集未声明。避免方法：把所有代码打包进本地扩展、只申请必需权限、提供清晰的隐私政策与功能说明、用官方工具做权限与 manifest 自查。AMO 对 Firefox 的审核同样严格，重点看权限合理性与代码安全。

审核被拒是"合规没做好"的反映。工程上把权限最小化、代码本地化、隐私声明化作为开发规范，而非事后补救，能大幅降低被拒概率。

• store 分发的灰度与回滚限制
• 自托管 update_url 的灰度与回滚能力
• 发布策略的工程取舍

Chrome Web Store 分发拥有广覆盖与自动审核，但灰度能力有限（虽可按比例/地区发布，控制力弱），回滚需重新提审新版本，周期长。自托管 update_url 让扩展完全控制灰度（按用户/IP/内网比例下发特定版本）与回滚（立即更换 update 清单指向旧版本），但需要自建更新服务器与签名、维护成本高。取舍：公共产品用 store 为主（简单合规），企业/内网或需要精细灰度控制时用自托管，兼顾两者可做"store 兜底 + 内网自托管"。

灰度与回滚是发布策略的核心。自托管在"控制力"上占优，store 在"分发与合规"上占优，工程上按产品形态与环境选择或组合。

• MV3 WAR 按资源 + 来源（matches/ids）匹配
• 路径与扩展级别的精确暴露
• 防止任意网页滥用资源

MV3 中 web_accessible_resources 的每个资源必须声明允许访问的来源：用 matches 限定 Web 源、用 extension_ids 限定扩展 ID，并精确到资源路径。这样任意网页只有在其来源被白名单允许时才能加载该资源，否则访问被拒。最小暴露意味着：只暴露必要资源、路径尽量精确、来源尽量收窄，避免用宽泛通配。这切断了"任意网页通过扩展资源 URL 做跨域读取/利用"的路径。

WAR 的最小暴露是"按资源+按来源"双维度收紧。工程上应把暴露面视为攻击面，逐项审查每个 resources 与 matches，杜绝宽泛声明。

• permissions.request 需在用户手势中触发
• onRemoved 监听权限撤销
• 功能降级与用户提示

chrome.permissions.request 必须在用户手势（如点击按钮）的上下文回调中调用，否则会被拒绝；其返回的 Promise 可判断用户是否授予。权限被撤销时（用户手动移除或 chrome.permissions.onRemoved 触发），扩展应监听该事件，检测受影响权限并降级对应功能（禁用相关 UI、提示用户重新授权或说明影响），避免功能异常。降级设计应保证核心功能仍可用，仅受影响的能力受限。

用户手势是权限请求的硬约束，onRemoved 是权限状态变化的监听。工程上把"权限状态"作为一等状态管理，统一处理授予/撤销/拒绝四种路径，保证 UI 与能力一致。

• Notification.permission 的状态机
• Geolocation 权限与用户导航
• 权限生命周期与持久化

Notification 权限状态为 granted/denied/default，通过 Notification.requestPermission() 请求，用户可永久授予或拒绝；Geolocation 通过 navigator.geolocation 请求，权限由浏览器管理，用户可撤销。这些 Web 权限与扩展权限相互独立，状态持久化到浏览器，用户可随时在设置中修改。扩展需在权限被拒或撤销时检测并降级（如隐藏通知功能、提示用户开启）。注意：MV3 的 Service Worker 中需用 chrome.notifications 或 offscreen 来触发 Web 通知。

Web 权限生命周期是"请求-授予-撤销-重请求"的状态机。工程上应把权限状态持久化、监听变化并优雅降级，避免用户关闭权限后功能报错。

• 多浏览器/多版本测试矩阵
• 特性检测（feature detection）
• CI 自动测试与回归

跨浏览器兼容依赖两层：一是特性检测——运行时用 capability detection（如检查 chrome.scripting 是否存在、browser 命名空间是否可用）而非假设插件存在；二是测试矩阵——在 CI 中对 Chrome/Firefox/Edge/Safari 及关键版本跑自动化测试（单元 + 集成 + 扩展 E2E），覆盖各浏览器差异路径。工程上把矩阵与构建产物、API 差异表绑定，形成回归基线。

兼容性不是"写一次跑所有"，而是"检测 + 矩阵 + 回归"。特性检测避免运行时崩溃，测试矩阵保证跨环境行为一致，二者结合是跨浏览器工程的基石。

• 权限提示的滥用与用户流失
• 按需、及时、可解释的权限请求
• 权限请求的交互设计

权限提示滥用（如一打开就请求一堆权限、请求与功能无关的权限）会削弱用户信任、降低安装转化率、增加被拒与卸载风险。良好的权限提示设计：按需申请（在用户真正需要该功能时再请求）、一次只请求必要权限、用浅层 UI 解释"为什么需要"、提供拒绝后的降级路径、减少反复打扰。工程上把权限请求与用户操作绑定，减少过度弹窗。

权限提示是用户信任的"第一印象"。工程上应把权限请求做成"有价值的、可解释的、及时的"，配合按需与降级，让用户自然理解并授权。

• 用户手动撤销站点权限
• chrome.permissions.onRemoved 监听
• 功能降级与用户提示

用户可在扩展详情页手动编辑站点访问权限（移除某站点访问），导致 tabs/activeTab 等权限失效。扩展应通过 chrome.permissions.onRemoved 与 chrome.permissions.getAll 监听权限状态变化，检测到失效后对受影响功能降级（禁用相关 UI、提示重新授权），并校验当前站点权限再执行操作。activeTab 失效是"一次性授权"，需在再次点击时重新获取。

权限状态是动态的，不能假设"安装即永久有效"。工程上把权限状态纳入运行时管理，监听变化并实时降级/提示，保证 UI 与真实能力一致。