javascript主执行线程是单线程的，1. 它通过事件循环机制实现异步非阻塞操作，将耗时任务委托给宿主环境处理并在完成后回调；2. 宏任务（如settimeout、i/o）和微任务（如promise回调）按优先级调度，每个宏任务执行后必先清空所有微任务再执行下一个宏任务；3. web workers和node.js的libuv线程池在主线程外利用多线程处理计算或i/o密集型任务，并通过消息或回调安全地与主线程通信，保持主线程单线程本质的同时提升整体并发能力。
JavaScript在浏览器或Node.js环境中，其主执行线程确实是单线程的，这意味着它一次只能处理一个任务。但它并非不能处理耗时操作，而是通过事件循环（Event Loop）机制，将那些耗时或异步任务“委托”出去，并在完成后再回调主线程，从而在单线程的表象下，实现了非阻塞的异步操作。
JavaScript的单线程特性，从根本上讲，是为了简化编程模型。你想想看，如果DOM操作是多线程的，那多个线程同时修改同一个元素，会引发多少竞态条件和锁的问题？简直是噩梦。所以，它选择了一条相对简单且安全的路：一个主线程，负责执行所有的JS代码，包括DOM操作、变量赋值、函数调用等等。
这个选择带来了一个显而易见的问题：如果一个任务非常耗时，比如一个复杂的计算，或者网络请求，那主线程就会被“卡住”，页面会冻结，用户体验极差。这就是为什么我们需要异步机制。JavaScript本身并没有提供多线程能力（Worker除外，但那是另一个层面的东西，不影响主线程的单线程本质），它依赖宿主环境（浏览器或Node.js）提供的API，比如setTimeout, XMLHttpRequest, fetch, Promise等，将这些耗时操作交给宿主环境去处理。当这些操作完成时，宿主环境会将一个“事件”或“回调”放入一个队列中，等待主线程空闲时来处理。这个处理机制的核心，就是事件循环。
立即学习“Java免费学习笔记（深入）”；
JavaScript主线程与任务队列（Task Queue）的关系是怎样的？
理解事件循环，得先搞清楚主线程和任务队列的互动。想象一下，主线程就像一个永不停歇的工人，它有一个“待办事项清单”（调用栈，Call Stack），里面的任务一个接一个地执行。当遇到一个异步任务时，比如发起一个网络请求，主线程不会傻傻地等着它完成。它会把这个任务交给宿主环境（比如浏览器的网络模块）去处理，然后自己继续执行“待办事项清单”上的下一个任务。
当宿主环境处理完这个异步任务后，它不会直接把结果扔回给主线程。相反，它会把一个与这个异步任务相关的“回调函数”或者说“事件消息”放到一个叫做“任务队列”（Task Queue，也叫消息队列或回调队列）的地方。这个队列里可能已经有其他完成的异步任务回调了。
主线程会在什么时候去这个队列里取任务呢？只有当它的“待办事项清单”（调用栈）完全清空，也就是当前正在执行的所有同步代码都跑完了，它才会去“事件循环”（Event Loop）那里询问：“任务队列里有新的任务吗？”如果有，事件循环就会把队列里的第一个任务（回调函数）推到主线程的调用栈上，让主线程去执行。这就是它们之间的基本协作模式。
宏任务（MacroTask）与微任务（MicroTask）在事件循环中如何调度？
事件循环的复杂性，很大程度上体现在它对不同类型任务的调度优先级上。并非所有异步任务的回调都一视同仁地排队。JavaScript引入了宏任务（MacroTask）和微任务（MicroTask）的概念，来精细化调度。
宏任务包括但不限于：setTimeout、setInterval、setImmediate（Node.js特有）、I/O操作、UI渲染事件（浏览器）。当一个宏任务的回调准备好时，它会被放到宏任务队列中。
微任务则包括：Promise的回调（then、catch、finally）、MutationObserver的回调、process.nextTick（Node.js特有）。微任务有更高的优先级。
事件循环的执行流程是这样的：
- 执行当前的宏任务（通常是整个script脚本）：主线程首先执行调用栈中的所有同步代码，这可以看作是一个大的宏任务。
- 清空微任务队列：当当前的宏任务执行完毕，调用栈清空后，事件循环会立即检查微任务队列。如果微任务队列不为空，它会把队列中的所有微任务依次取出并执行，直到微任务队列清空。
- 执行下一个宏任务：微任务队列清空后，事件循环会去宏任务队列中取出一个宏任务来执行。
- 重复步骤2和3：循环往复，直到两个队列都清空。
这意味着，在执行完一个宏任务之后、执行下一个宏任务之前，所有的微任务都会被优先执行。比如，你发起一个网络请求，它返回的Promise的then回调会作为微任务处理，而一个setTimeout的回调则作为宏任务。所以，即使setTimeout(0)，它也总是在当前所有的微任务执行完毕之后才有可能被执行。这种机制确保了某些高优先级、需要即时响应的异步操作（如Promise链）能更快地得到处理。
Web Workers和Node.js的I/O操作如何与JavaScript的单线程模型协同工作？
尽管JavaScript主线程是单线程的，但这并不意味着它完全无法利用多核CPU的优势，或者在处理I/O密集型任务时效率低下。这得益于宿主环境提供的额外机制。
在浏览器环境中，Web Workers提供了一种在后台线程中运行JavaScript脚本的能力。一个Web Worker是完全独立于主线程的，它有自己的全局作用域，不能直接访问DOM。它们之间通过postMessage方法进行通信。这意味着你可以把一些计算密集型的任务（比如大数据处理、图像处理）放到Worker线程中去执行，而不会阻塞主线程，从而保持页面的响应性。当Worker完成任务后，它会通过消息机制通知主线程，主线程再根据消息更新UI。这并非改变了主线程的单线程本质，而是提供了一种“绕过”单线程限制，利用多线程能力的手段。
而在Node.js环境中，情况略有不同。Node.js的强大之处在于其非阻塞I/O模型。虽然Node.js的JavaScript执行也是单线程的，但其底层是用C++编写的libuv库，这个库负责处理所有的I/O操作（文件读写、网络请求等）。libuv本身是多线程的（它维护了一个线程池），当Node.js的JavaScript主线程发起一个I/O请求时，libuv会将这个请求交给其内部的线程池去处理。当I/O操作完成时，libuv会将相应的回调函数放入Node.js的事件循环的宏任务队列中，等待JavaScript主线程空闲时去执行。
所以，无论是Web Workers还是Node.js的libuv，它们都是在JavaScript主线程之外，利用操作系统的多线程能力来处理耗时操作，然后通过事件循环机制将结果或回调安全地传递回单线程的JavaScript主线程，从而实现了看似“异步”和“并发”的效果，而主线程本身依然保持着其单线程的特性。这是一种非常巧妙且高效的设计。
