推荐

本文是个人阅读推荐，非原创。原文作者：腾讯云开发者社区 为什么推荐这篇文章 学 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、网络请求等异步操作时，自己不会去做，而是交给浏览器的其他线程（定时器线程、网络线程等），完成后把回调函数放回任务队列，等主线程空闲时再执行。这就是发布订阅模式的实际应用。 ③ 微任务优先级高于宏任务 ...

一个经典的困境 你是一个前端工程师或技术负责人。你发现网站慢得要命，性能指标惨不忍睹。你想花两个 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、媒体、政府网站等等。不管你在什么行业，大概率能找到跟你相似的案例。 每个案例都有源头 — 不是凭空捏造。每条数据都引用原始来源，可以直接拿来写提案。 ...

网站： martinfowler.com 站长： Martin Fowler — Thoughtworks 首席科学家，《重构》《企业应用架构模式》作者 创立时间： 2000 年左右，bliki 始于 2003 年 有些网站，你第一次点进去觉得平平无奇，但第二次、第三次之后，它会慢慢变成你查资料时的默认起点。 martinfowler.com 对我来说就是这样的存在。 一个什么样的网站？ 如果用一句话概括，这是一个软件工程的深度内容站。没有广告，没有付费墙，没有"优化阅读体验"的弹窗。就是白底黑字，配上偶尔的代码块和图表。 站长 Martin Fowler 是 Thoughtworks 的 Chief Scientist，写过几本改变行业面貌的书——1999 年的《重构》让"改善既有代码的设计"成为程序员的必修课，2002 年的《企业应用架构模式》给了无数后端开发者一套通用词汇表。 但这不只是他个人的博客。他自己说：“这个网站最开始只是放我自己的文章，但随着它越来越受欢迎，我开始用它帮别人的好文章获得更多曝光。” 于是每篇文章都经过他本人的筛选和编辑——质量远重于数量。这种克制让网站二十多年积累的内容始终保持在一个可被信任的水准上。 Bliki：介于博客和维基之间 2003 年，Fowler 开创了一个叫 bliki 的格式——blog + wiki 的混合体。 普通博客是按时间线排列的，文章写完了就固定了。Wiki 是围绕主题组织的，可以持续更新。Bliki 试图结合两者：每篇文章围绕一个概念展开，像 wiki 词条一样精炼，但又保留作者的视角和叙事。 你去看看他的 Bliki 页面，会看到从 Architecture Decision Record 到 Microservices 再到 Technical Debt 的条目。很多我们日常挂在嘴边的术语，最早的清晰定义就出自这里。 比如 ADR（架构决策记录）——这个如今被广泛采用的实践，他那篇 2026 年 3 月的 bliki 条目就是最好的入门材料之一：简短、清晰、实用，几页纸说清楚为什么要写、怎么写、写多长。 那些改变行业的概念 这个网站是不少行业关键概念的"爆发地"： Microservices（微服务） —— 2014 年，Fowler 和 James Lewis 联合撰写的那篇定义性文章，到现在还是讨论微服务时被引用最多的文献之一。“微服务是一套小型的、自治的服务，每个服务围绕业务能力构建……“这段话就是从这儿来的。 ...