浏览器扩展中fetch跨域的核心是通过manifest声明host_permissions合法突破限制，而非绕过同源策略；需在background/service worker中发起请求，content script须委托通信；应遵循最小权限与csp安全原则。
浏览器扩展中用 Fetch 跨域获取远程数据，核心不是“绕过”同源策略，而是利用扩展特有的权限机制合法突破限制。普通网页受制于浏览器安全沙箱，而扩展通过 manifest 配置可主动声明跨域能力，这是关键区别。
manifest.json 中正确声明 host 权限
扩展必须在 manifest.json 的 permissions 或 host_permissions 字段中明确列出目标域名。从 Manifest V3 开始，推荐使用 host_permissions：
- 支持通配符：如
"https://api.example.com/*"、"*://*.github.com/*" - 支持协议限定：必须写明
https://或http://，不能只写域名 - 避免过度授权：不要用
"<all_urls>"</all_urls>，除非确实需要访问任意网站
示例配置：
"host_permissions": [ "https://jsonplaceholder.typicode.com/*", "https://httpbin.org/*" ]
Fetch 请求无需额外设置 mode 或 credentials（默认即生效）
只要权限已声明，直接调用 fetch 即可跨域，不需要手动设 mode: 'cors' 或 credentials: 'include' —— 这些是网页环境的补救手段，在扩展中反而可能引发异常。
- 扩展发起的请求不受 CORS 预检限制，GET/POST/PUT 等方法均直通
- 若需携带 Cookie（如登录态），才需显式加
credentials: 'include' - 响应头中的
Access-Control-Allow-Origin对扩展无效，服务器不必设置
避免在 content script 中直接跨域（安全隔离要求）
content script 运行在网页上下文中，仍受同源策略约束。即使扩展有权限，content script 发起的 fetch 也会被拦截。
- 正确做法：将跨域请求逻辑放在 background script 或 service worker 中
- content script 通过
chrome.runtime.sendMessage向后台发起请求委托 - 后台处理完数据后，再把结果发回 content script 渲染
敏感接口调用需配合 CSP 与最小权限原则
扩展权限越大，安全风险越高。尤其涉及用户数据或第三方 API 时：
- 在 manifest 中启用
content_security_policy，禁止内联脚本和 eval - 对返回的 JSON 数据做基础校验（如字段存在性、类型检查），不直接
eval或插入 DOM - 若调用需 token 的私有 API，token 应存于
chrome.storage.local，而非硬编码在代码里
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
