sharedworker 是浏览器中唯一能天然串行化多标签页请求、避免重复拉取同一 api 的机制，通过单线程排队执行并精准回传响应；需同源部署、正确 mime 类型、id+端口绑定、三级缓存、超时兜底及手动清理 pendingrequests。
SharedWorker 是目前浏览器中唯一能天然串行化多标签页请求、避免重复拉取同一 API 的机制——它不是靠“加锁”或“广播通知”，而是把所有请求收口到一个线程里排队执行，响应再精准回传。
SharedWorker 必须同源部署且不能内联
你不能用 new SharedWorker('data:...') 或 Blob URL；必须提供一个真实可访问的同源 JS 脚本路径，比如 /workers/cache-manager.js。否则 Chrome 会报 SecurityError: Failed to construct 'SharedWorker': Script at ... violates the following Content Security Policy directive。Safari 对此更严格，甚至拒绝加载 localhost 上未启用 HTTPS 的脚本（开发时可用 https://localhost 或 127.0.0.1 绕过）。
- 确保服务器返回正确的 MIME 类型：
application/javascript - Vite 项目中需写成
import SharedWorker from './cache-manager.js?sharedworker'，否则构建后路径失效 - Webpack 需配
shared-worker-loader，否则new SharedWorker('./x.js')会 404
请求-响应必须带唯一 ID + 端口绑定
多个标签页同时调用 fetch('/api/user')，Worker 若不区分来源，就会把响应发错端口。不能依赖 port.postMessage() 的隐式顺序，必须显式配对：
- 页面发送时附带自增 ID：
port.postMessage({ id: ++reqId, type: 'GET', url: '/api/user' }) - Worker 用
Map存映射：pendingRequests.set(id, { port, resolve, reject }) - fetch 完成后查 ID 回传：
pendingRequests.get(id)?.port.postMessage({ id, data, status: 200 }) - 务必在
port.onclose中清理该 ID，否则内存泄漏 + 响应丢失
缓存策略要兼顾时效性与一致性
单纯“第一次请求存、后续直接返回”会出问题：比如用户在标签页 A 修改了配置，标签页 B 还在用旧缓存。推荐三级缓存结构：
- 内存缓存（
Map<string data timestamp></string>）：5 秒内相同 URL 直接返回，避免瞬时并发 - IndexedDB 缓存：存完整响应体 +
ETag或Last-Modified，用于下次请求时带If-None-Match校验 - 强制刷新开关：页面可发
{ type: 'REFRESH', url }，Worker 清对应内存项并重 fetch
注意：不要在 Worker 里用 localStorage 存缓存——它不是线程安全的，多端口写入会覆盖。
超时、失败、页面崩溃必须主动兜底
某个标签页崩溃或网络中断，它的请求可能卡在队列里，或者 pendingRequests 里留着已失效的 port 引用。这会导致整个队列阻塞：
- 每个请求设 8 秒超时：
setTimeout(() => reject(new Error('Timeout')), 8000) - 超时后从队列中移除，并触发下一条 —— 否则后续请求永远等不到
- 监听
port.onclose，及时从pendingRequests和待处理队列中删除关联项 - 页面卸载前主动 close：
window.addEventListener('beforeunload', () => port.close())
最易被忽略的是：Worker 本身没有自动 GC 机制，pendingRequests 和队列数组若不手动清理，内存会持续增长，数小时后标签页变卡甚至崩溃。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
