在 Linux 环境下，Node.js 应用的内存优化其实有不少门道。很多开发者觉得内存问题比较玄学，但其实只要抓住几个关键点，就能让应用跑得既稳又省资源。下面把这些思路拆开来讲，每个方向都值得在实际项目中落地。

先从最核心的引擎说起。Node.js 底层依赖 V8 引擎，它提供了两种内存管理策略：稳定（Stable）模式和快速（Fast）模式。稳定模式倾向于降低内存占用，但会牺牲一点执行性能；快速模式则反过来，反赌但吃内存更多。怎么选？完全取决于你的应用场景。可以在启动时通过 --max-old-space-size 参数来指定具体策略，比如需要高并发低延迟就选快速，对内存敏感的场景就切到稳定。

如果你的应用里用了子进程（比如通过 child_process 模块），那每个子进程的内存也要单独管控。同样可以用 --max-old-space-size 参数给子进程设定内存上限，防止某个子进程把整个系统的内存都吞掉。

排查内存问题，工具是少不了的。Node.js 自带了一个 heapdump 模块，可以生成堆快照进行分析。社区里还有 memwatch-next 和 node-memwatch 这些第三方库，能帮你实时监控内存变化，定位泄漏点。用好这些工具，内存优化就有了数据支撑，不再是盲人摸象。

代码层面的习惯也很重要。全局变量是个容易忽略的坑——它们在整个应用生命周期里都活着，一旦引用链没清理干净，就会造成内存泄漏。尽量多用局部变量，用完后及时赋值为 null，让垃圾回收器能正常回收。

对于重复计算或频繁访问的数据，缓存是经典解法。但缓存也不是越多越好，得控制大小。比如用 LRU（最近最少使用）策略来缓存热点数据，既能提升性能，又不会让内存无限制膨胀。

数据结构的选择也直接影响内存占用。举个例子，当你要存储大量键值对时，Map 比 Object 更高效——Map 在内存布局上做了优化，插入和删除操作也更省资源。类似地，数组比链表在某些场景下更紧凑，需要根据实际访问模式来权衡。

事件监听器是另一个容易翻车的地方。如果注册了监听器却忘记移除，回调函数和它引用的外部变量都会一直留在内存里。特别是那些一次性事件，使用 once 方法注册，或者主动在合适时机调用 removeListener，能避免很多泄漏。

处理大文件或大数据流时，千万别一次性全部读到内存里。Node.js 的流（Stream）机制就是为此设计的——用 pipe 或事件驱动的方式逐步处理数据，内存占用可以控制在极低水平。比如处理几十 GB 的日志文件，用流几乎不会撑爆内存。

最后还有一个很实用的运维手段：定期重启。哪怕代码写得再干净，长期运行的应用也可能因为各种原因积累内存碎片或泄漏。通过进程管理器（比如 PM2）设置自动重启策略，比如每天凌晨重启一次，就能把内存状态重置到初始水平。这不失为一种兜底方案。

以上这些方法组合起来，基本能覆盖 Linux 下 Node.js 应用内存优化的主要场景。从引擎策略到代码习惯，从工具监控到运维手段，每一步都值得细化落地。