JavaScript单线程执行意味着同一时间只能处理一个任务，导致耗时操作会阻塞页面响应；为优化体验，浏览器通过async和defer属性实现脚本异步加载，避免阻塞HTML解析，其中async脚本下载后立即执行，不保证顺序，而defer脚本在DOM解析完成后按序执行；更复杂的执行顺序由事件循环机制调控，它协调宏任务（如setTimeout）与微任务（如Promise回调），确保微任务优先于宏任务执行，从而形成一套高效、非阻塞的异步编程模型。
浏览器中的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
的回调等。它的优先级比宏任务队列高。
事件循环的工作流程大致是这样的：主线程会先清空调用栈中的所有同步代码。一旦调用栈为空，事件循环就开始检查微任务队列。如果有微任务，它会把所有微任务都取出来，逐个推入调用栈执行，直到微任务队列清空。清空微任务队列后，事件循环才会去宏任务队列中取出一个宏任务（比如一个
setTimeout的回调），推入调用栈执行。执行完毕后，再次检查微任务队列，如此循环往复。
这种机制就解释了为什么
Promise.resolve().then(...)会比
setTimeout(..., 0)先执行。因为
Promise的回调是微任务，而
setTimeout的回调是宏任务，微任务在每个宏任务执行前，都会被优先清空。理解了这一点，你就能更好地预测和控制异步代码的执行顺序，编写出更健壮、更可控的JavaScript应用。这对于调试复杂的异步逻辑，简直是救命稻草。
