北京
这是 DEV 社区 Summer Bug Smash 挑战的投稿。我删除了 payment worker 里的一行 `console.log`，合并 PR 后去倒了杯茶。十分钟后，PagerDuty 开始疯狂报警。 后台 Pod 的内存使用率飙到了 99.8%，出站 webhook 报出 orphan closure 错误，Postgres 里的行开始被不同用户的 payload 覆盖。我慌了，立刻 revert 了这个 commit，把 `console.log` 又加了回去。 然后就像变魔术一样……错误消失了。内存降回 180MB，一切恢复绿色。 回滚一个单行 PR 就能让生产环境自愈，这件事本身就让人脊背发凉。它说明你的架构根本不稳定——它只是靠偶然的副作用在硬撑。如果加一行 `console.log` 就能修好后端，那你依赖的是运气和操作系统的缓冲时序。 我花了 14 小时反复抓堆快照（`node --inspect`）、对比不同 GC 周期下的内存 dump，才搞清楚底层发生了什么。 当我移除那行 log 后，V8 的 JIT 优化被触发。在激进的垃圾回收过程中，V8 在后台回调还没写完 Redis 之前，就把父上下文标记为“已死亡”。回调最终解析到了一个无效的 scope context。 原始代码大致是这样的： ```js app.post('/api/checkout', async (req, res) => { const user = req.user; db.saveOrder(req.body).then(async (order) => { await telemetry.logTransaction(user.id, order.amount); }); return res.json({ status: "queued" }); }); ``` 问题在哪里？外层的 async 函数会在 `db.saveOrder` 事务完成之前就 return 响应，而 Promise 链里的回调持有 user 对象和请求上下文。移除 `console.log` 后，V8 认为这个上下文已经没有外部引用了，于是把它当作垃圾提前回收。实际上，后续的 `telemetry.logTransaction` 仍然需要它。 修复方式是用 Node.js 的 `AsyncLocalStorage` 来显式管理异步上下文： ```js import { AsyncLocalStorage } from 'node:async_hooks'; const asyncLocalStorage = new AsyncLocalStorage(); app.post('/api/checkout', async (req, res) => { const userId = req.user.id; const payload = req.body; try { const result = await asyncLocalStorage.run({ userId }, async () => { const order = await db.saveOrder(payload); await telemetry.logTransaction(userId, order.amount); return order; }); return res.json({ status: "queued", orderId: result.id }); } catch (error) { return res.status(500).json({ error: "checkout_failed" }); } }); ``` 关键点是：不要依赖隐式作用域存活，把事务内的关联数据用 `AsyncLocalStorage` 或权威事务句柄显式传递。还有一点，这次事故让我深刻理解了一个道理——在 Node.js 后端里，代码是给人和 GC 共同维护的。看似“多余”的日志行，可能正在帮你维持一些你还没意识到的生命周期约束。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
