Shared Worker 是前端唯一可行的跨页面带宽协调载体，通过请求级节流、动态降级与服务端协同实现应用层带宽调控，而非底层抢占。
Shared Worker 本身不调度网络带宽，也不直接控制带宽分配。它无法干预 TCP 层的流量控制、浏览器内核的连接限速，或操作系统级的网卡调度。所谓“动态调配多窗口网络带宽占用”，在前端实际可行的范畴内，是指通过 Shared Worker 统一协调多个页面的请求节奏与资源使用策略，间接影响带宽消耗分布——本质是应用层的请求节流与优先级管理，而非底层带宽抢占。
Shared Worker 是跨页面调度的唯一可行载体
- 普通 Worker 每个标签页独占一个实例，无法感知其他页面行为
- Service Worker 无法维持长连接，也不能主动发请求，只响应 fetch、message、push 等事件
- 只有 Shared Worker 在同源下被所有页面共用，且生命周期独立：只要还有一个同源页面打开，它就持续运行，适合做全局状态中枢
这意味着，带宽相关的协调逻辑（比如限制并发请求数、延迟非关键请求、按业务类型分级发送）必须全部收敛到 Shared Worker 内实现，不能分散在各页面中。
请求级节流：用权重+队列模拟带宽配额
Shared Worker 可为每个接入页面分配一个逻辑标识（如 clientId），并维护一个请求队列。结合简单权重机制，实现近似带宽比例分配效果：
- 页面注册时上报自身业务类型（如
"dashboard"、"log-viewer"、"notification"） - Worker 根据类型预设权重（例如 dashboard=3，log-viewer=2，notification=1）
- 所有请求进入统一队列，Worker 按权重轮询各页面的待发请求（类似 WRR 思路，但以请求为单位，非报文）
- 每轮最多允许每个页面发出
weight个请求，发完即跳过，避免某页面独占通道
这种方式不改变单个 HTTP 请求的带宽，但能拉平多窗口下的瞬时流量峰谷，缓解服务端压力，也降低浏览器因并发超限（如 Chrome 的 6 个 HTTP/1.1 连接）导致的排队阻塞。
动态降级：后台页面自动让出带宽优先级
页面切到后台时，主线程可能被冻结，定时器失效，但 Shared Worker 仍活跃。可利用此特性做智能让渡：
- 页面通过
document.hidden监听 +postMessage主动通知 Worker：“我已后台” - Worker 将该页面标记为
lowPriority，将其请求插入队列尾部，或延后 500ms 再调度 - 若页面重新激活，立即提升其调度权重，并清空延迟队列中的旧请求
- 对 WebSocket 场景，后台页面可暂停心跳和订阅更新，仅保留基础连接保活
这比依赖浏览器自动节流更可控，尤其适用于仪表盘类多开场景，避免十几个标签页同时轮询造成带宽挤兑。
服务端协同才是带宽调控的关键闭环
纯前端调度存在明显边界：
- 无法限制单个请求的数据体积（如大文件下载）
- 无法感知真实网络质量（RTT、丢包率）
- 无法区分上行/下行瓶颈
因此，Shared Worker 应配合服务端能力形成闭环：
- 页面上传前先向 Worker 发起带宽探查请求（如
/api/bw/probe?size=1024） - Worker 聚合所有页面的探查结果，汇总上报服务端（含 clientId、timestamp、耗时）
- 服务端根据全局负载返回建议速率（如
"maxUploadBps": 512000） - Worker 将该策略广播给对应页面，由其控制分块上传大小与间隔
这种“前端统一分发 + 服务端集中决策”的模式，才能真正实现动态、可反馈的带宽调配。
不复杂但容易忽略。
