很多从前端转 Node.js 的开发者，对这门运行时的理解停留在"写 JavaScript，能跑服务"这个层面。开发环境跑得好好的，上了生产环境，问题一个接一个冒出来，而且每一个都反直觉。

这不是水平问题，是 Node.js 的运行时设计给了你一种安全感——一种在开发环境完全验证不了、只有在流量压上来的那一刻才会破碎的安全感。

我自己在做 BFF 层的这些年，踩过太多这种坑。最深的感触是：Node.js 不会替你兜底，它只是让你以为它会。

事件循环不是安全网

Node.js 的文档里有一句很关键的话：事件循环在单个线程中运行。但很多人对这句话的理解是——"异步代码就不会阻塞"。

这是最大的幻觉。

`async/await` 只是语法糖，它让异步代码看起来像同步代码，但它不会把同步操作变成异步的。当你在一个请求处理函数里做了这些事情，整个事件循环都会停住：

- `JSON.parse` 一个 50MB 的请求体
- 用正则表达式匹配一个精心构造的字符串（回溯攻击）
- 在同步循环里做密集计算，比如加密、排序大数据集
- 调用了某个底层 C++ 扩展的同步接口

在金融业务场景里，这种情况尤其容易发生。风控规则引擎、复杂的产品推荐计算、大量数据的重组——这些逻辑从前端搬过来的时候，很多人压根没意识到它们在 Node.js 里是同步执行的。前端里一个耗时 200ms 的计算，顶多让页面卡一卡；在 Node.js 里，这意味着所有其他请求排队等 200ms。

更阴险的是，这种问题在开发环境、甚至压测环境都很难发现。开发环境 QPS 低，200ms 的阻塞不会触发告警；压测通常用简单请求，不走复杂业务逻辑。到了生产环境，当你的 Node.js 进程同时在处理几百个请求时，一个同步阻塞就像高速公路上的车祸——后面全堵死了。

怎么解决？没有银弹。CPU 密集的逻辑要么拆成多个小块用 `setImmediate` 让出事件循环，要么干脆扔给 Worker Thread，要么老老实实让 Java/Go 的后端服务来做。BFF 层的定位是聚合和裁剪数据，不是做重型计算——这个边界一旦模糊，运行时幻觉就开始了。

V8 的垃圾回收不替你管内存

JavaScript 开发者普遍有一个根深蒂固的观念：不用手动管理内存，V8 会帮你回收。

这话对了一半。V8 确实会回收垃圾，但它回收的是"不可达"的对象。如果你的代码里还有引用指向那块内存，V8 就不会动它——不管你是不是真的还需要它。

生产环境里最常见的 Node.js 内存泄漏模式，没有一种是 V8 能帮你处理的：

闭包泄漏。中间件链里不小心把请求对象塞进了外部闭包，每个请求都留下一份引用，V8 认为这些对象还"活着"。这种泄漏在开发环境完全看不出来——你本地跑 100 个请求，泄漏 100KB 内存，Node.js 进程从 80MB 涨到 80.1MB，谁会注意？但生产环境七天不间断运行，每天几百万请求，内存曲线就是一条缓慢但坚定的上升线，直到触顶 OOM。

EventEmitter 监听器累积。`EventEmitter` 默认允许 10 个监听器，超过会打印警告。但很多人要么提高这个阈值，要么用 `prependListener` 偷懒，结果就是监听器只增不减。在长连接场景（WebSocket、SSE）里特别常见——每次连接注册监听器，断开时忘了移除。

全局缓存膨胀。这个在 BFF 层尤其典型——你用一个简单的 `Map` 或对象缓存后端接口的返回数据，心智模型是"过期了就删掉"。但你真的实现了 LRU 淘汰吗？你的缓存 key 有没有可能无限增长？当 key 的组合是 `userId + productId + date` 这样的结构时，全局缓存就是一个没有底部的漏斗。

Node.js 的默认堆内存上限在 64 位系统上是 1.4GB 左右（老版本更低）。这个数字看起来不小，但对一个长时间运行的 BFF 服务来说，如果不监控内存趋势，OOM 只是时间问题。

我的建议是：不要相信"V8 会处理"这句话。在生产环境，你必须监控内存趋势，而不是只看当前值。一个缓慢上升的内存曲线比一次突发的 OOM 更危险——后者至少你能立刻知道，前者可能在你完全没注意的时候突然崩掉。

PM2 Cluster 不是高可用

PM2 的 Cluster 模式让很多团队产生了一种错觉：多个 Worker 进程 = 高可用 = 可以随便挂。

不是这么回事。

首先，Cluster 模式下的多个 Worker 进程之间不共享状态。这意味着如果你的 BFF 层有内存中的 session、本地缓存、WebSocket 连接这些状态，Cluster 模式帮不了你——一个 Worker 挂了，它承载的状态就丢了。如果你依赖 Sticky Session（把同一用户的请求路由到同一个 Worker），一个 Worker 重启就意味着那批用户的体验中断。

其次，Master 进程本身是单点。PM2 的 Master 进程如果自身出问题（比如系统 OOM Killer 先把它干掉），所有 Worker 都会变成孤儿进程。你以为有进程管理器帮你拉起服务，但管理器自己挂了谁来拉？

第三，也是最容易被忽略的：健康检查的假阳性。PM2 默认判断 Worker 健康的方式是进程是否存活。但一个进入死锁状态的进程、一个事件循环被卡住的进程、一个端口还在监听但已经无法正常处理请求的进程——在 PM2 看来它都是"健康的"。你的监控报警说服务正常，但因为事件循环被阻塞，所有请求都在排队超时。

在 Kubernetes 环境下这个问题更加微妙。K8s 的 liveness/readiness 探针通常检查一个 HTTP 端口，但这个检查本身走的就是事件循环——如果事件循环卡住了，探针请求也会超时，K8s 才会重启 Pod。但这个超时时间可能已经很长了，你的用户在这段时间里已经承受了服务降级。

我的观察是：PM2 Cluster 可以帮你处理进程崩溃的快速恢复，但它不能替代真正的架构高可用设计。如果你的服务需要高可用，答案不在进程管理器里，在架构设计里——无状态化、外部化存储、熔断降级、多实例路由。

uncaughtException 不是万能兜底

Node.js 有一个臭名昭著的事件：`uncaughtException`。很多人在应用启动时加一行：

```javascript
process.on('uncaughtException', (err) => {
logger.error('Uncaught exception:', err);
});
```

然后心安理得地认为"所有未捕获的异常都被兜住了"。

这不是兜底，这是掩耳盗铃。

Node.js 官方文档明确说了：`uncaughtException` 之后进程的状态是不可预测的。可能一些内部状态已经损坏，可能某些异步操作已经被丢弃，可能连接池里有一个连接已经处于不确定状态。你 log 完错误继续让这个进程跑，就像一辆出过事故的车修了外壳接着开——你不知道底盘有没有裂。

更真实的情况是：很多团队既加了 `uncaughtException` 处理，又没有在处理完之后退出进程。结果是错误被吞掉了，服务看起来正常，但数据可能已经不一致了。在金融业务里这种问题尤其严重——一个转账请求处理到一半抛异常，你捕获了异常但没有回滚事务状态，用户的钱扣了但没到账。

`unhandledRejection` 这个坑在 Node.js 15 之前更隐蔽。在 Node.js 14 及之前，未处理的 Promise rejection 只会打印一个警告，不会退出进程。于是大量代码里 Promise 的 `.catch()` 被省略了，错误被静默吞掉。从 Node.js 15 开始默认行为改成了退出进程，这个改动让很多升级的应用直接在生产环境挂掉——不是 Node.js 变不稳定了，是之前的错误从来没有被正确处理过。

Domain 模块？已经废弃了。`async_hooks`？太底层，不适合做错误处理。目前最靠谱的做法其实很朴素：在每一层都做好错误处理，不要指望全局兜底；`uncaughtException` 和 `unhandledRejection` 的处理逻辑里只做一件事——记录错误，然后退出进程，让进程管理器拉起新实例。

优雅退出比你想象的难

优雅退出（Graceful Shutdown）的方案在网上到处都是：监听 `SIGTERM`，停止接收新请求，等现有请求处理完，关闭数据库连接，退出进程。

听起来很完美。但生产环境里，这个过程比写出来的复杂十倍。

时间不够用。Kubernetes 默认给 30 秒的优雅退出时间（`terminationGracePeriodSeconds`），包括从 kubelet 发送 SIGTERM 到容器被强制杀死的全部时间。但实际上，你的应用收到 SIGTERM 之前，Pod 可能已经从 Service 的 Endpoints 列表中被移除了——这意味着新的流量不再路由到这个 Pod，但正在处理的请求还需要时间完成。如果你的请求处理链路里有慢查询、外部服务超时等待，30 秒可能根本不够。

连接池清理是异步的。你的 BFF 层连着后端的连接池、Redis 连接池、Kafka producer，每个关闭操作都是异步的。如果你只是调用 `pool.close()` 就退出进程，正在传输中的数据会被截断。Kafka 的 offset 没提交完就会导致消息重复消费；数据库事务没提交就会回滚；Redis 的 SUBSCRIBE 连接没清理干净就会在下一次重连时收到重复消息。

定时任务的状态。BFF 层经常有定时任务——刷新本地缓存、同步配置、发送心跳。优雅退出时，这些定时任务的状态怎么处理？如果一个缓存刷新任务正在执行，你的关闭逻辑要不要等它完成？如果这个任务要跑 10 秒呢？

嵌套的关闭顺序。你的应用可能有这样的依赖链：HTTP Server → BFF 聚合层 → 后端 API Client → 连接池。正确的关闭顺序应该是反过来的：先停止接收新请求，等现有请求完成，关闭后端连接，最后关闭 HTTP Server。但很多框架的关闭 hook 只是一个简单的回调数组，执行顺序取决于注册顺序——如果你不小心先关闭了数据库连接池，正在处理的请求拿不到连接就会全部报错。

在金融场景里，优雅退出还要考虑一个更严苛的问题：资金操作不可中断。如果一个购买请求处理到一半——已经扣了用户余额但还没确认份额——这时候收到 SIGTERM，你不能简单地关闭连接、回滚事务。你需要有一个业务层面的补偿机制，而不只是技术层面的优雅退出。

---

说这么多，不是为了劝退——Node.js 在 BFF 层、中间件层的价值是实实在在的。前端同学可以用熟悉的语言写服务端逻辑，全栈团队的沟通成本大幅降低，生态工具链也足够成熟。

但"能用"和"能在线上跑得稳"之间，隔着的不是一段代码的距离，而是一整套对运行时的深度理解。事件循环的调度机制、V8 的内存模型、进程管理的真实边界、错误处理的底层行为、优雅退出的全链路设计——每一个点都值得你花时间去搞清楚，而不是等它在生产环境炸了才去补救。

Node.js 不会替你兜底。但它给了你足够的工具和能力去自己兜底——前提是，你知道哪些地方需要兜底。

很多人觉得 Node.js 简单，其实不是 Node.js 简单，是开发环境简单。生产环境的 Node.js，和你们本地 `npm start` 跑起来的那个 Node.js，根本不是同一个东西。