事件循环不分配cpu，只调度任务顺序；cpu占用由任务执行时长决定，同步代码会阻塞主线程；web worker可解耦cpu，实现非阻塞计算。
javascript 事件循环本身不直接“分配 cpu”，它只是协调任务执行的机制；真正决定何时占用 cpu、用多少资源的，是浏览器或 node.js 运行时的底层调度器与 javascript 引擎（如 v8）对任务的处理方式。
宏任务和微任务由事件循环按序调度，但执行时独占 CPU
JavaScript 是单线程的，同一时刻只能执行一个任务。当一个宏任务（如 setTimeout 回调、I/O 回调、script 初始化）开始运行，它会持续占用 CPU 直到执行完毕——中间不会被其他任务打断（除非遇到 await 或同步阻塞操作如 while(true)）。微任务（如 Promise.then、MutationObserver）在每个宏任务结束后立即批量执行，同样会连续跑完所有待处理微任务，期间也不让出 CPU。
- 一个耗时 100ms 的同步函数，会实实在在占用 CPU 100ms，期间页面无法响应点击、动画卡住
- 哪怕只写 while(Date.now() ，也会导致主线程冻结半秒
- 微任务队列清空前，新的宏任务（比如用户点击）会被挂起，等微任务全部执行完才进入下一轮循环
浏览器会主动干预长任务，但不改变 JS 执行模型
现代浏览器（Chrome、Firefox）会对超过 50ms 的任务标记为“长任务”（Long Task），并在性能面板中告警。部分浏览器还会在空闲时段尝试插入高优先级任务（如输入响应），但这属于渲染引擎层面的启发式优化，不是事件循环的职责。JS 引擎仍严格按宏/微任务队列顺序执行，不会自动拆分或中断你的代码。
- 没有“自动时间切片”——for 循环十万次就是一口气跑完
- requestIdleCallback 是唯一由浏览器提供的、让你主动让出 CPU 的接口，适合做低优先级后台工作
- 想避免卡顿，得自己把大任务拆成小块，用 setTimeout(() => {}, 0) 或 queueMicrotask 分段执行
Web Worker 是真正的 CPU 解耦方案
如果计算密集型逻辑必须执行，又不想阻塞主线程，唯一可靠的方式是移出事件循环：用 Web Worker 在独立线程运行 JS。Worker 内部也有自己的事件循环，但它的执行完全不占用渲染线程的 CPU 时间，主线程可照常响应用户、绘制动画。
- Worker 中不能访问 DOM，适合纯数据处理（加密、解析、搜索）
- 主线程与 Worker 通过 postMessage 通信，本质是异步消息传递，不共享内存
- Node.js 中可用 worker_threads 达到类似效果
事件循环不管理 CPU 分配，它只保证任务排队和触发顺序；CPU 时间由任务自身执行时长决定，而是否卡住页面，取决于你有没有写出长时间霸占线程的代码。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
