-
我在 JavaScript 里用 setTimeout 0 想让一段逻辑稍后立即执行来排个时序,结果它总是排在所有 Promise 回调的后面执行,输出顺序跟我写的顺序完全对不上,因为微任务永远先于宏任务的深度复盘
我有段逻辑想让它在当前同步代码跑完后尽快执行,用了 setTimeout(fn, 0),以为 0 毫秒就是马上、最先执行。可代码里同时还有 Promise.then 回调,运行结果让我懵了:setTimeout(0) 总是排在所有 Promise.then 回调的后面执行,日志顺序和书写顺序完全对不上,靠它排的时序也错乱。复盘才搞懂:JS 单线程靠事件循环调度异步,异步分宏任务(setTimeou…- 0
- 0
-
我写的 JS 里 setTimeout、Promise 和同步代码混在一起,打印顺序完全不按我写的来,Promise 居然比 setTimeout 先跑,我对着事件循环排查了大半天的复盘
我写了段混着同步代码、setTimeout、Promise.then 的逻辑,以为按从上到下书写顺序执行,结果打印顺序大跌眼镜:同步代码先全跑完,写在后面的 Promise.then 竟比写在前面、延迟为0的 setTimeout 先执行,依赖顺序的逻辑全乱了。深挖才懂是 JS 的事件循环:JS 单线程,执行规则是同步代码先跑完→清空整个微任务队列(Promise.then/await后/queu…- 0
- 0
-
我的 asyncio 服务接口全是 async/await,QPS 却低得离谱,我以为是部署配置问题,最后揪出一个同步的 requests 调用,把整个单线程事件循环死死卡住的深度复盘
我用 asyncio + FastAPI 写了个服务,接口全是 async def,每处该 await 的都 await 了,自以为是纯异步高并发。可压测时 QPS 低得怀疑人生,100 个并发像排队过独木桥一样串行处理。我一度怀疑 uvicorn worker 数、想上多进程,扒代码才发现罪魁祸首:一个 async 接口里,我图方便调了同步阻塞的 requests.get——它把整个单线程事件循…- 0
- 0
-
日志说完成数据却没动:forEach 异步陷阱避坑复盘
那次事故的现象一开始把整个团队都看懵了:一个跑批量数据处理的 Node.js 脚本,日志里明明白白打着全部处理完成共5000条,可数据库里实际被更新的却总是只有零星几十条,而且每次跑数量还不一样,脚本没报任何错退出码是0,一副我成功了的样子。一个声称自己全部完成、还没报错的程序,干的活却只有它声称的零头,这种嘴上说着完成了手上啥也没干完的诡异排查起来格外抓狂,连个错误堆栈都没有无从下手。查到最后根…- 0
- 0
-
请求集体卡顿、单核打满:Node.js 事件循环阻塞避坑
一个平时快得没存在感的 Node.js 服务,偶尔会"集体卡顿"——几乎所有接口在同一瞬间一起超时几秒,然后又一起恢复,像什么都没发生。病来得没规律,日志翻不出半个 ERROR,内存也稳,唯一可疑的是卡顿那几秒总有一个 CPU 核心瞬间被打满到 100%,其它核都闲着。这个"单核打满、其它核闲置"的画面,正是 Node 单线程特性在喊话:某个请求里藏着一坨不…- 0
- 0
-
页面为什么会卡死:从一个转不起来的 loading 说透 JS 事件循环
有个 bug 报上来时描述特别朴素:点了按钮,页面卡死三四秒,期间界面点不动,转圈的 loading 也不出现,等它缓过来结果直接就显示了。翻代码一看,setLoading(true) 和 setLoading(false) 一个没漏,可 spinner 就是死活不肯露面。根子在一个人人听过却很少想透的事实:JavaScript 是单线程的——那段同步的重循环死死霸占着唯一的线程,浏览器既没机会把…- 2
- 0
-
从一套用 callback 层层嵌套成回调金字塔向右缩进到屏幕边缘加 var 满天飞还到处污染全局加用 == 做隐式类型比较加在请求路径里同步阻塞加靠 console.log 调试加随手 npm install 锁不住版本的祖传 Node 服务、核心下单逻辑是五六层 callback 一层套一层嵌出来的厄运金字塔某个错误分支的回调里当年漏写了一个 return 平时流量从未触发可大促那晚高并发一压上来那条错误路径被频繁命中下单回调重复执行库存被重复扣减订单被重复创建瞬间一片超卖和重复订单、几乎同时另一个接口在请求处理路径里用 fs.readFileSync 同步读取一个随业务数据不断变大的配置文件又跟着一段同步 for 循环去处理它而 Node 是单线程事件循环这段同步代码一执行就好几秒这几秒里整个事件循环被死死阻塞健康检查下单查询所有请求全排在后面动弹不得瞬间集体超时负载均衡判定实例不健康摘了出去流量涌向其余实例又把它们一个接一个以同样方式压垮雪崩 + var 变量提升加函数作用域泄漏加经典循环闭包陷阱所有闭包共享同一个 var 变量等执行时循环已结束全打印成最终值 + == 隐式类型转换埋下空数组等于 false 字符串 1 等于数字 1 等诡异判断防不胜防 + callback 漏判 error 加 async 抛出却没人接最终 unhandledRejection 直接崩掉进程一个角落的疏忽干掉整个服务 + 靠全局变量和 script 加载顺序维系隐式依赖改一处牵全身 + 直接原地 mutate 共享对象与数组 push sort 原地改引发跨模块诡异 bug + 锁不住版本换台机器装出另一套我机器上是好的一上生产就报谁也没见过的错 → 2026 现代 Node.js 工程体系 Promise 加 async/await 扁平线性错误可被 try/catch 统一捕获 + 异步非阻塞 API 加 Worker threads 隔离 CPU 密集事件循环永不卡死 + const/let 块级作用域加 TDZ 声明即所见闭包符合直觉 + === 严格相等加显式类型转换比较行为可预测 + try/catch 加统一错误中间件加进程级兜底错误可见进程不裸崩 + ESM import/export 显式依赖边界清晰可静态分析可摇树 + 不可变更新展开解构数据流向可追副作用受控 + lock 文件加 npm ci 锁定整棵依赖树任何机器字节级一致 + pino 结构化日志加 jest 加 CI 自动回归 87 天战役复盘:8 个 P0 复盘 + 6 条工程哲学 + 7 个关键数字
6 人的后端团队 87 天把一套支撑公司电商订单与营销的核心后端 API,从一堆用 callback 层层嵌套成回调金字塔、var 满天飞还到处污染全局、用 == 做隐式类型比较、在请求路径里同步阻塞、靠 console.log 调试、随手 npm install 锁不住版本的祖传 Node 代码,系统性地现代化到基于 async/await 与 ESM 的现代 Node.js 工程体系。这套服务…- 0
- 0
-
从粗放 Node.js 服务 error-first 回调层层嵌套成七八层回调地狱读不懂改不动 + 同步阻塞 IO 和 CPU 密集计算把单线程事件循环死死卡住全请求被拖死超时 + CommonJS require 同步加载无法 tree-shake 产物臃肿 + error 被吞掉漏写 catch 未捕获 reject 直接崩进程 + Promise.all 一把梭几千请求无限并发瞬间打爆下游雪崩 + 大文件大响应一次性全读进内存 Buffer 暴涨 OOM + event listener 不解绑缓存无上限内存像漏水的桶涨到 OOM 重启 + 单进程只占一核其余核心全闲置浪费 + 满地撒 console.log 海量无结构日志大海捞针 → 2026 现代高性能后端 async/await 扁平化顺序读写 + 异步 IO 加 worker_threads 卸载 CPU 密集主线程畅通 + ESM import 静态可摇树 + 统一 try-catch 加错误中间件加 process 兜底 + p-limit 并发上限保护下游 + Stream 流式 pipeline 背压内存平稳 + 解绑加 WeakMap 加 LRU 上限治理内存 + cluster 多进程多核负载均衡 + pino 结构化日志加请求 id 全链路追踪 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
11 位 Node.js 后端工程师 87 天把一套跑了五年、业务量从每天几万请求涨到几千万请求后种种粗放写法集中爆雷的 Node.js 服务集群——大量异步逻辑用 error-first 回调一层套一层嵌套成七八层深的回调地狱金字塔加个错误处理都要每层重复写读都读不懂、有些地方图省事用 readFileSync 同步阻塞 IO 还有几处把 CPU 密集计算直接放主线程跑结果一个请求就把整个单线程…- 0
- 0
-
彻底搞懂 JavaScript 事件循环(Event Loop):宏任务、微任务与执行顺序详解
"JavaScript 是单线程的,那它为什么不会被一个耗时操作卡死?" "setTimeout(fn, 0) 为什么不是立刻执行?" "为什么 Promise 总比 setTimeout 先输出?" "为什么我明明先 setState 了,读到的还是旧值?" —— 这些问题的答案,全都指向同一个机制:事件循环(Eve…- 2
- 0
事件循环
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×