前端

这两年我看过市面上几乎所有 Promise 教程，但始终是一知半解。直到我搞清楚了浏览器多线程、事件循环和微任务，才迎来真正的顿悟。 前言：那些年我踩过的坑 Promise 的重要性不言而喻，可就是学不会。我看过阮一峰老师的教程，刷过各种视频，甚至能背出"链式调用、解决回调地狱"这些概念，但一碰到执行顺序的题目就懵。 最大的误解是什么？我以前一直以为"异步"就是 JS单线程同时处理多件事情，好像它能一边倒计时一边执行下面的代码。这种错误认知让我在面对 setTimeout 和 Promise 混用的代码时永远答不对。 直到我读了一篇文章 —— 《从浏览器多进程到JS单线程，JS运行机制最全面的一次梳理》，配合阮一峰的 Promise 教程重新学习，我才真正开了窍。 下面我把这次"顿悟"的过程完整梳理出来，希望能帮助那些和我一样曾经痛苦挣扎的同学。 一、核心突破：理解"单线程异步"的真正含义 误解 vs 真相 我曾经的误解 真正的机制 JS 自己一边倒计时一边执行后面的代码 JS 把定时任务交给浏览器的定时器线程去处理 异步就是单线程来回切换干不同的事 异步是发布订阅模式：订阅事件 → 别的线程执行 → 完成后把回调放回任务队列 Promise 构造函数里的代码也是异步的 Promise 构造函数内的代码同步执行，只有 .then 回调才是微任务 核心记忆：JavaScript 引擎是单线程的，但浏览器是多线程的。 当 JS 遇到 setTimeout(cb, 1000) 时，它不会自己倒计时。它会说：“定时器线程，请你在 1 秒后把这个 cb 函数放回任务队列。“然后自己立刻继续执行后续同步代码。定时器线程倒计时结束后，把 cb 塞进宏任务队列，等待主线程空闲时通过事件循环（Event Loop）取走执行。 这就是你理解的 “Promise 中去使用 event loop 以外的线程，然后发布订阅模式” —— 完全正确。 二、事件循环（Event Loop）与任务队列 一旦理解了上面的外包机制，事件循环就变得非常直观。 1. 两类任务 宏任务（MacroTask）：整体 script 代码、setTimeout、setInterval、I/O、UI 渲染。 微任务（MicroTask）：Promise.then()、Promise.catch()、MutationObserver。 2. Event Loop 执行顺序 执行一个宏任务（最开始就是整个 script 代码）。 执行过程中产生的所有微任务，放入微任务队列。 当前宏任务执行完毕后，立刻清空整个微任务队列。 进行必要的 UI 渲染。 从宏任务队列中取出下一个宏任务，循环往复。 关键点：微任务的优先级永远高于宏任务。先清空微任务，再取下一个宏任务。 ...

本文是个人阅读推荐，非原创。原文作者：腾讯云开发者社区 为什么推荐这篇文章 学 Promise、学 async/await、学事件循环——我相信大部分前端都经历过这个过程：看了无数教程，能背出"链式调用"“解决回调地狱"这些概念，但一碰到执行顺序的题目就懵。 问题出在哪？我们跳过了底层机制，直接去学上层 API。 这篇文章做了一件很多人没做过的事：从浏览器是多进程的这个事实出发，一路梳理到 JS 引擎的单线程本质，再到 Event Loop 的完整机制。 读完之后你会发现，Promise 的所有行为都变得合理且可预测，而不是需要死记硬背的"规则”。 文章讲了什么 大致脉络： 进程 vs 线程 —— 用工厂和工人的比喻讲清楚区别，不啰嗦 浏览器是多进程的 —— 每个 Tab 页是一个独立进程，Browser 进程、GPU 进程、渲染进程各司其职 浏览器内核（渲染进程）内部的线程关系 —— GUI 渲染线程与 JS 引擎线程互斥，这就是为什么 JS 会阻塞页面渲染 JS 引擎的单线程本质 —— JS 引擎线程一次只能做一件事，但浏览器其他线程可以并行 Event Loop 完整机制 —— 宏任务、微任务、任务队列，讲得非常透彻 定时器的真相 —— setTimeout 不是精确计时，而是交给浏览器定时器线程处理 最值得读的部分 我个人觉得最有价值的三个点： ① JS 引擎线程和 GUI 渲染线程互斥 这解释了为什么耗时的 JS 代码会导致页面卡顿——不是因为 JS “慢”，而是因为它们抢同一个线程，JS 执行时页面没法渲染。 ② 异步的本质是"外包" JS 遇到 setTimeout、网络请求等异步操作时，自己不会去做，而是交给浏览器的其他线程（定时器线程、网络线程等），完成后把回调函数放回任务队列，等主线程空闲时再执行。这就是发布订阅模式的实际应用。 ③ 微任务优先级高于宏任务 ...

一、为什么需要 SSE？ SSE（Server-Sent Events，服务器推送事件） 是一种基于 HTTP 的单向实时通信协议。与 WebSocket 的全双工不同，SSE 是 服务端 → 客户端 的单向推送，天然适合以下场景： 💬 实时聊天：接收对方发送的消息 🤖 AI 流式输出：ChatGPT 风格的逐字返回 📊 数据看板：实时刷新指标数据 🔔 消息通知：订单状态变更、审核结果推送 相比 WebSocket，SSE 的优势在于： 维度 SSE ✅ SSE ⚠️ 局限 基于 HTTP，天然支持认证、CORS ✅ 单向通信，客户端需另外发请求 自动重连机制（浏览器端） ✅ 浏览器限制最大 6 个并发连接 协议简单，调试方便 ✅ 不支持二进制数据 防火墙友好，不会被拦截 ✅ IE/Edge Legacy 不支持 二、浏览器中的 SSE 长什么样？ 在浏览器中，使用 SSE 非常简单： // 浏览器原生 EventSource —— 就这么简单 const es = new EventSource('/api/events'); // 监听默认消息 es.onmessage = (e) => { console.log('收到消息:', JSON.parse(e.data)); }; // 监听自定义事件 es.addEventListener('chat-message', (e) => { const msg = JSON.parse(e.data); renderMessage(msg); }); // 监听连接状态 es.onerror = () => console.log('连接断开，浏览器会自动重连'); 浏览器的 EventSource API 帮你处理了所有脏活累活： ...

一个经典的困境 你是一个前端工程师或技术负责人。你发现网站慢得要命，性能指标惨不忍睹。你想花两个 sprint 做性能优化，但老板问了一个问题： “做这个能带来多少收益？” 于是你沉默了。 你知道性能很重要，但你拿不出数据来支撑你的论点。 WPO Stats（wpostats.com）就是为了解决这个问题而生的。 WPO Stats 是什么？ 它是由 Web 性能领域两位重量级人物——Tim Kadlec 和 Tammy Everts（著有《Time is Money》）——共同维护的一个非商业项目，一个关于 Web 性能优化（WPO）对业务指标影响的数据案例库。 简单说：这里存了上百个真实世界的研究案例，每个案例都用冷冰冰的数字告诉你——性能优化真的能赚钱。 随便挑几个案例感受一下 Amazon — 页面加载时间每增加 100ms，销售额下降 1%。 Walmart — 页面加载时间从 7 秒优化到 2 秒，转化率提升了 2%。 Sunday Citizen — 优化 Core Web Vitals 后，LCP 改善了 25%，CLS 改善了 61%，跳出率下降 4%，转化率提升超过 6%。 某电商公司 — SpeedSense 帮他们做性能优化后，7.6% 的转化率提升，带来了约 600 万美元的年度收入增长。 这些不是拍脑门吹出来的数字，而是来自真实公司的真实案例，引用的是公开可查的数据来源。 为什么这网站做得很好？ 按指标筛选 — 你想论证性能影响转化率？点进去，所有关于转化率的案例列得清清楚楚。影响收入、跳出率、SEO、用户参与度？都有对应的标签分类。 超过十五年跨度 — 数据从 2006 年至今，覆盖的行业包括电商、SaaS、媒体、政府网站等等。不管你在什么行业，大概率能找到跟你相似的案例。 每个案例都有源头 — 不是凭空捏造。每条数据都引用原始来源，可以直接拿来写提案。 ...