manifest.json 权限会按原样进入构建产物。各目标之间的差别在于哪些权限会被保留,所以先从这里看起。
各目标如何处理该权限
一个声明了"proxy" 的清单,构建结果如下:
Safari 构建会打印原因:
设置固定代理
在后台 service worker 中配置代理,那里可以使用该 API:proxy 权限是必需的,Chromium 构建通常还需要覆盖目标站点的主机权限。
分发 PAC 脚本
PAC 脚本不是清单字段,因此打包器不会把它当作入口。它不会被计算哈希、重写路径,也不会自行进入产物。有两条可行路线。 把脚本作为 data 内联传入:public/ 目录里的内容会原样复制进构建产物,所以放在那里的 PAC 文件会以同名出现在 dist/<browser>/。从你自己的扩展源用 fetch 读取它,再把文本作为 data 传入。public/ 的作用见特殊目录。
处理代理认证
需要凭据的代理会触发chrome.webRequest.onAuthRequired。Manifest V3 移除了阻塞式 webRequest,因此应答该质询需要在 webRequest 之外再加上 webRequestAuthProvider 权限。
拦截网络请求介绍了 Manifest V3 保留的请求 API,以及 declarativeNetRequest 在哪里取代了阻塞式 API。
Firefox 的机制不同
Firefox 有一个同名权限下的代理 API,背后的模型不一样。Firefox 通过browser.proxy.onRequest 让扩展逐请求做决定,而不是存一份设置对象。
Extension.js 不会就这个差异发出警告。它的 Gecko 兼容性警告覆盖的是其他 API,因此一个 Chromium 形态的 chrome.proxy.settings.set 调用进入 Firefox 构建时不会有任何提示。请在 MDN 上确认该 API,并在发布前测试 Firefox 目标。
也可以只代理开发浏览器
有时你想代理的是开发期的浏览器,而不是扩展。这时传浏览器参数,而不是用扩展 API:browserFlags 配置项。

