JavaScript 自诞生之日起就被设计为单线程语言——同一时间只能执行一段代码，无法像 Java 或 C++ 那样创建多个线程并行处理任务。这一特性并非技术局限，而是深思熟虑后的架构选择，其根源在于 JavaScript 最初的核心使命：在浏览器中操作 DOM 并响应用户交互。
6.1.1 单线程的本质：一个调用栈，一条执行线
所谓单线程，指的是 JavaScript 引擎内部只有一个执行栈（Call Stack）。代码按照顺序被压入栈中执行，执行完当前帧才会处理下一帧。这意味着：
- 一段代码在运行时，不可能有另一段代码同时修改同一个变量或 DOM 元素。
- 开发者不必面对多线程编程中最棘手的竞态条件和锁机制问题。
对于前端开发者而言，这种简单性极其珍贵。试想一下，如果多个线程同时操作一个 textarea 的内容、同时修改一段文字的样式，你将不得不写大量同步代码来保证界面的一致性。而单线程让一切操作都串行化，逻辑天然安全。
6.1.2 设计原因：DOM 操作的确定性
为什么浏览器端的脚本语言一定要单线程？核心原因在于 DOM 的可变状态。
DOM（文档对象模型）是一棵树状结构，代表网页的全部内容和元素。如果 JavaScript 是多线程的：
- 线程 A 正在删除某个节点
- 线程 B 同时试图修改该节点的文本内容
浏览器该如何处理？无论先执行谁，都可能产生非预期的结果。即便引入复杂的锁机制，也极大增加开发复杂度和运行时开销。而将 JavaScript 设计为单线程，就从根本上避免了对 DOM 的并发修改问题，使得页面渲染和交互逻辑变得可预测、可调试。
这一选择与“事件驱动”设计互为表里。既然 JavaScript 只能单一执行，就必须有一种机制让耗时操作（网络请求、用户事件、定时器）不会堵塞界面。于是，“异步非阻塞”和“事件循环”应运而生——这些将在后续章节详细展开。
6.1.3 单线程的现代挑战与应对
单线程并非完美方案。如果一段代码长时间占用主线程（例如执行大量计算、遍历巨型数组），整个页面就会“卡死”：按钮无法点击、动画停止、滚动失效。这正是我们常说的“阻塞主线程”。
实际问题举例：
- 从一万条数据中筛选匹配项，可能造成短暂卡顿。
- 处理图片压缩、加密解密等计算密集任务时界面完全无响应。
好在 JavaScript 生态提供了多种应对策略：
- 异步拆分：将长任务拆成多个小片段，利用
setTimeout或requestIdleCallback在事件循环的空档执行。 - Web Worker：浏览器提供的“后台线程”，可以执行 JavaScript 但不直接操作 DOM，通过消息传递与主线程通信，实现“计算离开主线程”。
- Service Worker：独立的代理线程，处理缓存、网络请求等，不依赖页面存活。
这些机制让 JavaScript 既能保持单线程模型带来的简洁安全，又能借助辅助线程处理重型任务，实现“看起来的并行”。
总之，单线程模型是 JavaScript 与生俱来的基因，它成就了 Web 开发的低复杂度，也带来了一些必须正视的瓶颈。理解它的本质和产生原因，是进一步掌握异步编程、性能优化的起点。