浏览器JS执行顺序规则？-js教程-PHP中文网

JavaScript单线程执行意味着同一时间只能处理一个任务，导致耗时操作会阻塞页面响应；为优化体验，浏览器通过async和defer属性实现脚本异步加载，避免阻塞HTML解析，其中async脚本下载后立即执行，不保证顺序，而defer脚本在DOM解析完成后按序执行；更复杂的执行顺序由事件循环机制调控，它协调宏任务（如setTimeout）与微任务（如Promise回调），确保微任务优先于宏任务执行，从而形成一套高效、非阻塞的异步编程模型。

浏览器js执行顺序规则？

浏览器中的JavaScript执行，从宏观上看是单线程、同步阻塞的，但现代前端开发中，异步机制（如事件循环、Promise、async/await）和脚本加载优化（如

async

登录后复制

、

defer

登录后复制

属性）极大地改变了这种简单模型，使得实际的执行顺序变得更为复杂和精妙。它不像我们想象的那么直接，背后有一套精心设计的规则在运作。

要说浏览器里JavaScript的执行顺序，这事儿真不是一两句话能讲清的，它像个层层嵌套的洋葱。最基础的，浏览器在解析HTML文档时，如果遇到

<script>

登录后复制

标签，它会停下来（解析阻塞），先下载脚本，然后执行脚本，执行完了才继续解析HTML。这是最原始、最“粗暴”的同步模式。

但我们都知道，这种阻塞体验太差了，尤其是脚本文件大的时候，页面会白屏很久。所以，后来就有了各种优化手段。比如，把

<script>

登录后复制

标签放到

<body>

登录后复制

底部，这样至少能让HTML结构先渲染出来。再后来，HTML5引入了

async

登录后复制

和

defer

登录后复制

这两个属性，它们就像给脚本加载和执行开了“绿色通道”，让脚本下载不再阻塞HTML解析。

async

登录后复制

属性的脚本会在下载完成后立即执行，不等待HTML解析，也不保证脚本间的执行顺序。这有点像“谁先到谁先吃”的自助餐。而

defer

登录后复制

属性的脚本则会在HTML解析完成后、

DOMContentLoaded

登录后复制

事件之前，按照它们在文档中出现的顺序依次执行。这更像“排队领餐，但可以提前准备好”。

除了这些加载层面的优化，JavaScript语言本身也进化出了强大的异步能力。事件循环（Event Loop）是理解JS异步执行的关键。它把那些耗时的操作，比如网络请求、定时器、用户交互，从主线程上“剥离”出去，交给Web APIs处理，等结果准备好了，再把回调函数放到任务队列里，等待主线程空闲时去执行。这里面还有微任务（Microtask）和宏任务（Macrotask）的区别，微任务（比如Promise的回调）总是优先于宏任务（比如

setTimeout

登录后复制

的回调）执行，这又是一层精细的调度。

所以，一个页面上，你可能会看到

<script>

登录后复制

标签里的同步代码、

async

登录后复制

加载的脚本、

defer

登录后复制

加载的脚本，以及各种异步操作的回调函数，它们在浏览器这个大舞台上，按照一套复杂的优先级和调度机制，共同编织出最终的执行顺序。这套机制，既保证了用户体验，又让开发者能够编写出高效、响应迅速的应用。

为什么说JavaScript是单线程的，以及它如何影响执行顺序？

JavaScript是单线程的，这个概念初听起来可能有点反直觉，毕竟我们平时用浏览器感觉它能同时做很多事。但这里说的“单线程”特指JS引擎在执行代码时，只有一个主线程负责处理所有的任务。这就意味着，同一时间，它只能做一件事。

这就像一个厨师，他一次只能炒一道菜。如果他正在切菜（执行同步代码），那么他就不能同时洗碗、烧水。一旦有任何一个任务需要长时间运行，比如一个复杂的计算循环，或者一个没有

async

登录后复制

或

defer

登录后复制

修饰的同步脚本，它就会霸占这个唯一的线程，导致页面卡死，用户界面失去响应——我们常说的“页面冻结”或“卡顿”就是这么来的。

我记得刚开始写前端的时候，就吃过这种亏，一个不小心写了个死循环，整个浏览器标签页就挂了。这深刻说明了单线程的局限性。为了避免这种尴尬，开发者必须学会把耗时的操作“外包”出去，或者拆分成小块，让主线程能定期喘口气，去处理UI渲染、用户输入等其他重要任务。这也是为什么异步编程在JavaScript中如此重要的原因，它不是为了多线程，而是为了在单线程模型下模拟并发，提升用户体验。

async

登录后复制

和

defer

登录后复制

属性是如何改变脚本加载和执行行为的？

async

登录后复制

和

defer

登录后复制

这两个属性，对于前端性能优化来说，简直是神来之笔。它们彻底改变了传统

<script>

登录后复制

标签阻塞解析的“霸道”行为。

序列猴子开放平台

具有长序列、多模态、单模型、大数据等特点的超大规模语言模型

查看详情

想象一下，没有

async

登录后复制

和

defer

登录后复制

时，浏览器遇到

<script src="..."

登录后复制

，就像被点穴一样，必须停下来，下载这个脚本，然后执行它，才能继续往下解析HTML。如果脚本很大，或者网络不好，用户就只能对着一个空白或半成品页面发呆。

有了

async

登录后复制

，脚本的下载是异步的，不阻塞HTML解析。一旦下载完成，它会立即执行。但这里有个关键点：它不会等待HTML解析完成，也不会管其他

async

登录后复制

脚本的顺序。哪个脚本先下载完，哪个就先执行。这对于那些不依赖DOM结构、也不相互依赖的独立脚本（比如统计代码、广告脚本）非常有用，能让它们尽快运行。但如果脚本之间有严格的依赖关系，或者需要操作完整的DOM，

async

登录后复制

就可能导致问题，因为它执行时DOM可能还没解析完，或者依赖的脚本还没加载。

而

defer

登录后复制

则更“绅士”一些。它的下载也是异步的，不阻塞HTML解析。但它的执行时机有所不同：它会等到整个HTML文档解析完成后，并且在

DOMContentLoaded

登录后复制

事件触发之前，按照它们在文档中出现的顺序依次执行。这意味着，

defer

登录后复制

脚本执行时，DOM已经完全构建好了，而且它们能保证执行顺序。这对于那些依赖DOM结构、并且有明确执行顺序要求的脚本（比如大部分业务逻辑脚本）来说，是更安全、更可靠的选择。

我个人在项目里，如果脚本之间没有明确依赖，或者优先级不高，会倾向于用

async

登录后复制

来争取更快的加载和执行；而对于那些核心业务逻辑、需要操作DOM的脚本，

defer

登录后复制

几乎是我的首选，它能确保一切就绪后再开始工作，避免了很多不必要的运行时错误。

理解JavaScript事件循环（Event Loop）对掌握异步执行顺序有何关键作用？

事件循环（Event Loop），这玩意儿是JavaScript异步编程的“幕后英雄”，也是很多初学者（包括我当年）觉得最烧脑但也最关键的概念。如果你不理解它，那么

setTimeout(..., 0)

登录后复制

为什么不是立即执行，Promise为什么比

setTimeout

登录后复制

优先级高，这些问题就会让你困惑不已。

简单来说，事件循环就是浏览器（或Node.js）用来协调主线程和各种异步任务的一套机制。它由几个核心部分组成：

调用栈（Call Stack）：这是JavaScript主线程执行同步代码的地方，遵循“先进后出”的原则。当一个函数被调用，它就被推入栈中；执行完毕，就被弹出。
Web APIs：这是浏览器提供给JS引擎的一些API，比如
```
setTimeout
```
登录后复制
、
```
fetch
```
登录后复制
、DOM事件监听等。当JS代码调用这些API时，它们会被“送”到Web APIs去处理，主线程得以继续执行后续的同步代码，而不会被这些耗时操作阻塞。
任务队列（Task Queue / Callback Queue / Macrotask Queue）：当Web APIs中的异步操作完成时（比如定时器时间到了，网络请求返回了数据），它们对应的回调函数并不会立即回到调用栈执行，而是会被放到这个任务队列里排队。
微任务队列（Microtask Queue）：这是一个特殊的任务队列，专门用来存放微任务，比如Promise的回调（
```
.then()
```
登录后复制
,
```
.catch()
```
登录后复制
,
```
.finally()
```
登录后复制
)、
```
MutationObserver
```
登录后复制
的回调等。它的优先级比宏任务队列高。