-
我图省事调了个异步函数发通知,既没 await 也没 catch,想着失败了无所谓,结果它一旦 reject 整个 Node 进程就因为未处理的 Promise 拒绝直接崩溃退出:一次 unhandled rejection 拖垮服务的深度复盘
我有个发通知的异步函数 sendNotification(user),心想通知失败也无所谓、不影响主流程,就图省事写成 fire-and-forget:sendNotification(user)——既没 await 也没 .catch(),调完不管。平时风平浪静,直到某次通知下游抽风、它内部的 Promise reject 了,而我没有任何地方处理这个 reject,整个 Node 进程因为 U…- 2
- 0
-
我把一个 async 方法的返回类型写成了 async void,它里面抛的异常 try-catch 死活拦不住、还直接把整个进程干崩了:一次 C# async void 吞掉异常、让异常逃逸到顶层崩溃进程的深度复盘
我们有个后台服务,我图省事把一个普通异步方法的返回类型写成了 async void,还在调用处包了 try-catch 自以为万无一失。可一旦方法内部抛异常,诡异的事发生了:try-catch 根本没拦住、异常像幽灵穿透了它,而且未捕获的异常直接让整个进程崩溃退出。查到底才明白:async void 是专为事件处理器(签名要求 void)设计的、不该用在普通异步方法上;它无法被 await,调用处…- 0
- 0
-
我用 forEach 配 async/await 批量处理数组,在 forEach 后面以为全都处理完了,结果它根本没等就往下走了,数据全乱套,我对着 forEach 不会等待异步回调这个坑排查了大半天的复盘
一个让我对 JavaScript 异步与数组遍历的结合彻底搞清楚的坑,诡异在我在每个元素上都老老实实写了 await 看起来应该会等,可整个 forEach 根本没等任何一个异步操作完成就执行到了后面。要对数组每个元素做异步操作(逐个存库)再汇总,自然用了 items.forEach(async (item) => { await saveToDb(item) }),然后 console.l…- 2
- 0
-
我在一个异步方法上用 .Result 同步等了一下结果,整个请求就这么永远卡死了,没有任何报错也没有超时,我对着 async 配 .Result 造成的死锁这个坑排查大半天的复盘
一个让我对 C# async/await 从会用到敬畏的经典坑,折磨在它不报错不抛异常不超时,只是静悄悄永远卡死在那,请求转圈到天荒地老、日志却干干净净。老项目里要在一个同步方法里调一个异步方法拿数据,图省事没把整条链改异步,直接在异步方法后加了 .Result 想同步等结果:return GetDataAsync().Result。这在控制台可能正常,但放到旧版 ASP.NET、WPF、WinF…- 2
- 0
-
我的 C# 异步方法明明用 try-catch 包住了,里面抛的异常却直接崩了整个进程、catch 根本没拦住,我对着 async void 排查了大半天的复盘
后台服务里的事件处理逻辑,有个异步方法处理事件,我很小心地在调用处用 try-catch 包住,自以为万无一失。可生产上一旦方法内部抛异常整个进程就直接崩溃,try-catch 像不存在一样什么都没捕获到。盯着代码百思不得其解:异常明明在 try 块里抛的 catch 凭什么没接住?排查大半天才发现罪魁是个不起眼的细节——我把异步方法返回类型写成了 async void 而不是 async Tas…- 0
- 0
-
我在 C# 里随手把异步方法写成了 async void,结果里面抛的异常我的 try-catch 怎么都抓不到、还直接把整个进程干崩了,我排查了大半天的复盘
我顺手把一个业务异步方法写成了 async void,平时没事,直到某天它内部异步调用抛了异常——我在调用处用 try-catch 严严实实包着,异常却完全没被 catch 到,还直接把整个进程干崩了。深挖才懂全是 async void 的锅:它无法被 await,调用方调用后立刻往下走,等 100ms 后异步操作真正抛异常时,外层代码早执行完、离开那个 try-catch 了;更致命的是 asy…- 0
- 0
-
点一下按钮整个界面就卡死,CPU 还是 0%:我在 C# 里对一个 async 方法调了 .Result,亲手制造了一场异步死锁的复盘
点一下按钮,整个桌面程序界面瞬间卡死、未响应,可任务管理器里 CPU 占用却是 0%——典型的死锁征兆。真凶是我在 UI 线程里对一个 async 方法调用了 .Result 同步等待:UI 线程被 .Result 阻塞,而 await 之后的代码又必须回到这条被占死的 UI 线程,两者互相等待。这篇从同步上下文与 await 的回归机制讲起,梳理"异步到底"与 Configu…- 0
- 0
-
日志说完成数据却没动:forEach 异步陷阱避坑复盘
那次事故的现象一开始把整个团队都看懵了:一个跑批量数据处理的 Node.js 脚本,日志里明明白白打着全部处理完成共5000条,可数据库里实际被更新的却总是只有零星几十条,而且每次跑数量还不一样,脚本没报任何错退出码是0,一副我成功了的样子。一个声称自己全部完成、还没报错的程序,干的活却只有它声称的零头,这种嘴上说着完成了手上啥也没干完的诡异排查起来格外抓狂,连个错误堆栈都没有无从下手。查到最后根…- 0
- 0
-
服务器很闲却瘫了:.NET 异步死锁避坑复盘
一个跑了两年都好好的 .NET 接口,某天起在流量高一点的时段就大面积超时,请求像泥牛入海一样卡住不返回。我第一反应是哪儿慢了,可登上服务器一看更懵:CPU 占用才百分之十几,内存宽裕,数据库一点不慢,可就是请求堆积、响应不出来——一个不忙的服务器,却服务不了请求。抓内存 dump 看线程栈才发现真相:进程里堆积着大量工作线程,几乎全卡在同一行形如 GetDataAsync().Result 的调…- 2
- 0
-
忘了一个 await:TS 浮动 Promise 乱序吞错避坑
有个用 TypeScript 写的下单流程:扣库存、写订单、再发通知,每步封装成 async 函数主流程里一个个调过去,代码写得很顺。可上线后偶发诡异:有时订单写进去了库存却没扣、有时通知发了订单还没落库,还有一次某步明明内部抛了异常外层 try/catch 却完全没捕获到、错误像人间蒸发既没日志也没告警只留一堆对不上的脏数据。逻辑明明是顺序写的怎么会乱序还吞异常?逐行抠 async 调用才发现真…- 9
- 0
-
一行 .Result 拖垮整个应用:C# 异步死锁避坑
一个平时跑得稳稳的 ASP.NET 老项目,我给某接口加了点新功能、调用了异步 HTTP 客户端取下游数据,本地测一切正常,压测时却出了鬼:并发一上来接口就大面积超时,不是慢,是彻底卡死永远不返回,而且会蔓延,最后整个应用线程池仿佛被冻住,连其它正常接口也没了响应,重启能缓解、一压又复现。我先怀疑下游慢、线程池太小,抓 dump 一看线程没在干活,而是齐刷刷阻塞在同一行我自以为无害的代码:var …- 0
- 0
-
压测一上量接口全超时:C# async/await 死锁与线程池饥饿
一次本该平平无奇的上线前压测,把并发拉到几百之后整个服务就像被掐住了脖子:响应时间从几十毫秒飙到十几秒,最后大面积超时——可机器的 CPU 占用还不到 20%,内存也宽裕得很。这种"不忙却瘫"的景象比 CPU 打满还让人发毛。排查一圈数据库和下游都没问题,直到拉出线程池指标才发现真相:工作线程被一口气全占满,而它们没一个在干活,全都阻塞在一个 await 上睡觉等结果。凶手是一…- 2
- 0
-
从古老 .NET Framework 4.x 体系 应用只能跑 Windows 挂 IIS 换不动平台 + 全程同步阻塞 IO 一上量线程池就耗尽假死 + 数据访问 ADO.NET 手写 SQL 字符串拼接埋着注入隐患 + 序列化全靠 Newtonsoft 反射又慢又吃内存 + 依赖全靠手动 new 或硬塞第三方容器对象图一团乱 + Web 层还是 Web Forms 老 MVC 一堆样板 + 值类型装箱拆箱满天飞 GC 压力山大 + 到处 NullReferenceException 半夜被叫起来查空指针 + 配置塞 web.config 的 XML 里改一下要重启 + 启动靠 global.asax 满地反射又慢又黑盒 → 2026 现代 .NET 8/9 体系 跨平台自宿主 Kestrel 容器化 + async/await 全链路异步 + EF Core 参数化 ORM + System.Text.Json 源生成序列化 + 内建依赖注入容器 + Minimal API + Span/Memory 零分配高性能 + 可空引用类型消灭空指针 + appsettings.json + IOptions 强类型配置 + 顶级语句 + Generic Host 通用主机 + Upgrade Assistant 渐进迁移 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
12 位 .NET 平台与后端工程师 87 天把一套用了八年的粗放 .NET Framework 4.x 体系——应用先天只能跑 Windows 必须挂在重量级 IIS 里进不了 Linux 容器、全程同步阻塞 IO 处理线程执行到查库调接口就死等白白占着一上量线程池瞬间耗尽服务假死而 CPU 闲着、数据访问用裸 ADO.NET 把 SQL 字符串拼接出来埋着致命注入隐患还要手写开连接建命令绑参数…- 0
- 0
-
从 .NET Framework 4.6 + WebForms/MVC5 混搭 + 全程同步阻塞 + 仅 Windows IIS + Entity Framework 6 + Web.config 配置地狱 + 静态类 new 满天飞无依赖注入 远古 .NET 体系 → 2026 .NET 9 现代运行时 + ASP.NET Core Minimal APIs + async/await 全异步 + 跨平台容器化 + EF Core + 内置 DI 与 Options 配置 + record/模式匹配/可空引用类型 + System.Text.Json 源生成器 现代 .NET 体系 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
13 位 .NET 平台工程师 87 天把一套跑了九年的 .NET Framework 4.6 远古体系——WebForms/MVC5 混搭、全程同步阻塞、被 Windows IIS 焊死、EF6 重包袱、Web.config 配置地狱、对象到处 new 无法测试——用增量迁移零停机重构到 2026 年现代 .NET 体系:迁移到跨平台高性能的 .NET 9 运行时、ASP.NET Core Mi…- 0
- 0
-
.NET 8 数据网关 P99 每 18 分钟飙到 4.2 秒的 5 天复盘:async 三连击反模式 + ThreadPool 饥饿定位 + 4 种修法 + 12 条 async 纪律
我们的 .NET 8 + ASP.NET Core 实时数据网关每 18 分钟出现 P99 4.2 秒尖刺,5 天定位到 .Result 同步阻塞 + 缺 ConfigureAwait + 自定义同步 Logger 三连击导致 ThreadPool 饥饿,4 种修法把 P99 稳定回 28ms。- 2
- 0
-
FastAPI 每隔 6 小时变僵尸:SQLAlchemy async 连接池静默泄漏 4 天复盘
FastAPI + SQLAlchemy 2.x async 服务每 6 小时连接池打满变僵尸。根因:Depends 用 return 而非 yield + 中间件吞掉 CancelledError + SQLAlchemy close 时机微妙。完整复盘 + 5 层修法 + 监控告警。- 0
- 0
-
C# async-over-sync 反模式 + HttpClient 端口耗尽两连击雪崩复盘:从 P99 11s 到 115ms 的全过程
一个 ASP.NET Core 服务在大促预热被两个 .NET 经典反模式同时打中:async-over-sync 的假异步引发 ThreadPool 饥饿,叠加 new HttpClient 引发端口耗尽,CPU 才 28% 但 P99 飙到 11 秒。本文复盘事故时间线、五种修法、性能基准对比、以及我们立下的 8 条 .NET 异步纪律,帮所有 .NET 团队避开同样的雪崩。- 0
- 0
async
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×