javascript宏任务队列不跨tab共享，每个tab拥有独立的渲染进程、调用栈及宏/微任务队列；后台tab会被浏览器降频调度，但事件循环仍自治运行。
JavaScript 的宏任务队列本身**不跨浏览器 Tab 页面共享或调度**——每个 Tab 是独立的渲染进程（或至少是独立的 JavaScript 执行上下文），彼此之间没有共用的宏任务队列。所谓“Tab 间资源调度”，实际是浏览器内核（如 Chromium）在系统级对 CPU、内存、网络、定时器等资源做的统筹管理，而非 JS 事件循环层面的队列协调。
每个 Tab 拥有完全隔离的事件循环
现代浏览器（Chrome、Edge、Firefox 等）普遍为每个 Tab 分配独立的渲染进程（或使用站点隔离策略）。这意味着：
- 每个 Tab 有自己的调用栈、宏任务队列、微任务队列和 Web API 宿主环境
-
setTimeout、setInterval、I/O 回调等宏任务只在本 Tab 的队列中排队与执行 - 一个 Tab 中运行的长任务（如密集计算）不会阻塞另一个 Tab 的宏任务调度，但可能因 CPU 争抢导致整体响应变慢
浏览器内核会对后台 Tab 主动降级调度优先级
为节省资源，浏览器会对非活跃 Tab（即用户未聚焦的 Tab）实施策略性限频：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
setTimeout/setInterval的最小延迟被拉长（Chrome 中通常限制为 ≥ 1000ms，即使设为 0 或 1） - 页面可见性 API（
document.visibilityState）可检测状态，但不改变队列结构，只影响宿主环境如何“投递”回调 - 后台 Tab 的 requestAnimationFrame 被暂停，
fetch请求仍可完成，但其 Promise.then 回调仍按本 Tab 微任务规则执行
资源竞争发生在系统层，而非 JS 队列层
多个 Tab 同时运行高负载脚本时，感知到的“卡顿”或“延迟”来源是：
- CPU 时间片被操作系统或浏览器调度器分配给不同进程，导致某 Tab 的宏任务实际开始执行的时间延后
- 内存压力触发 V8 垃圾回收（GC）频率上升，GC 是全停顿操作，会影响所有 Tab 的主线程，但 GC 本身不属于宏/微任务队列中的任何一项
- 网络请求共用浏览器的连接池与带宽，但响应到达后，各 Tab 仍各自将回调推入自己的宏任务队列
开发者无法干预跨 Tab 队列调度
JavaScript 标准与浏览器 API 均未提供访问或控制其他 Tab 任务队列的能力。跨 Tab 通信只能通过有限机制实现：
-
postMessage+SharedWorker：消息传递会触发接收方 Tab 的宏任务（message事件） -
BroadcastChannel：同源 Tab 间广播，事件回调进入各自宏任务队列 - Storage 事件（
localStorage/sessionStorage）：修改触发其他 Tab 的storage事件，属宏任务
这些机制都遵循“发送不阻塞、接收走本队列”的原则，不打破单 Tab 事件循环自治性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
