在 Linux 环境下运行 Node.js 应用时，内存优化是一个不可忽视的核心问题——尤其是在流量攀升后，稍有不慎的内存泄漏就可能导致进程毫无预警地崩溃。本文系统梳理了从代码层到系统层的多种优化策略，下面逐项展开分析。 首先，**代码层面的基本功**是最值得优先投入精力的方向。全局变量应尽量避免使用，因为一旦创建，它们会持续驻留在老生代中难以释放。处理大文件时，务必采用流（Streams）而非一次性将整个文件加载到内存，否则再大的物理内存也难以支撑。数据结构的选择同样关键：如果涉及大量数值运算，Typed Arrays 的性能远优于普通数组。至于内存泄漏——这一顽疾难以彻底杜绝，最核心的防范措施是确保不再被引用的对象能够及时被垃圾回收机制识别并回收。 内置模块常被低估，却价值显著。例如 `Buffer`，Node.js 的 Buffer 底层直接通过 C++ 管理内存，速度远超大多数第三方库。因此，凡能用内置模块解决的场景，应优先选用，避免引入外部依赖。 当涉及第三方库时，**选库策略需注重控制力**：优先选择轻量级方案，能少安装一个依赖就少装一个。同时尽量使用最新版本——并非盲目追新，而是新版通常修复了旧版本中存在的内存浪费问题。 进程管理方面，PM2 如今几乎是 Node 应用的标配工具。它不仅能通过多实例运行实现负载均衡，还可监控每个进程的内存占用，一旦超过预设阈值便自动重启。这一机制对于临时性内存泄漏能起到“先稳住局面”的应急效果。 V8 引擎本身也提供了丰富的调优参数。`--max-old-space-size` 用于限制老生代的最大内存占用，防止应用耗尽系统资源；`--optimize_for_size` 则促使 V8 更积极地优化内存布局。合理配置这两个参数，可显著减少内存碎片。 单凭直觉判断内存问题并不可靠，**必须借助专业工具**。Heapdump 可以捕获堆快照，Chrome DevTools 或 Node 自带的 `--inspect` 模式则能像医生查看 CT 影像一样，分析内存中对象的分布情况。哪些对象本应回收却未回收，一目了然。 缓存策略同样不容忽视。如果数据库查询频繁，使用 Redis 或 Memcached 将热数据缓存起来，以内存换取 IO 效率，性能提升极为显著。并发控制同样值得关注：请求量过大时，所有请求同时堆积在内存中等待处理，极易撑爆内存。引入队列系统，限制同时处理的请求数量，能有效降低峰值内存占用。 Node 的 `cluster` 模块是充分利用多核 CPU 的利器——每个工作进程拥有独立的内存空间，相互隔离，非常适合对稳定性要求较高的场景。最后，操作系统层面的参数也需配合调整，例如 `vm.swappiness`（控制内核使用 swap 的倾向）与 `vm.overcommit_memory`（控制内存过量分配策略），正确配置这些参数，能让 Node 进程在 Linux 上运行更加稳健。 内存优化从来不是一次性任务。推荐的做法是逐一尝试优化策略，每调整一处就持续监控，观察内存曲线的变化。因为应用在演进，流量在波动，优化方案也必须随之迭代。这才是正确的解决之道。