低配单核容器跑 Node 应用易卡死，核心矛盾是事件循环、V8 堆内存与 Docker 资源限制未对齐；必须显式设 --max-old-space-size（如 256）、--cpus 和 --memory，并禁用 swap，调试时需额外压低内存限额。
低配单核容器跑 Node 应用，不是“能不能跑”，而是“跑多久就卡死”。根本矛盾在于 Node.js 的事件循环 + V8 堆内存 + Docker 资源限制三者没对齐，稍一疏忽就会触发 OOM Killer 杀进程或 CPU 100% 锁死。
Node 进程启动时必须显式设置 --max-old-space-size
Node 默认堆内存上限是 1.4GB（V8 早期版本）或动态计算值（新版），但在 1 核 + 512MB 内存的容器里，这个值远超可用物理内存。不设限会导致 GC 频繁、内存碎片堆积、最终被 Linux OOM Killer 终止。
-
--max-old-space-size=256是安全起点：对应 512MB 容器内存，留出一半给系统、内核、Node 运行时开销 - 若应用含大量 JSON 解析或 Buffer 操作，需压到
--max-old-space-size=192，否则首次大请求就触发 GC stall - 别信
process.memoryUsage()返回值——它只报 JS 堆，不包含 libuv 线程池、C++ addon、文件句柄等原生内存，实际占用常高出 30%~50%
Docker run 必须带 --cpus 和 --memory 且不可省略
Docker 默认不限制资源，单核容器在负载突增时会抢占宿主机全部 CPU 时间片，导致宿主机卡顿甚至 SSH 断连。更危险的是：未设 --memory 时，OOM Killer 不按容器边界杀进程，可能误杀其他关键服务。
- 最低可行命令：
docker run --cpus=1 --memory=512m --memory-swap=512m -it node:18-alpine node --max-old-space-size=256 app.js -
--memory-swap=512m强制禁用 swap，避免磁盘 IO 拖垮响应——低配机器上 swap 比 OOM 更慢、更不可控 - 用
docker stats实时观察MEM USAGE / LIMIT，一旦接近 90%，说明--max-old-space-size还得往下调
Dev Container 的 devcontainer.json 里 resource limits 不生效？
VS Code Remote-Containers 扩展默认忽略 docker run 级别的资源限制，它依赖 Docker Desktop 的全局配置或 Compose 文件。直接写 "runArgs": ["--cpus=1", "--memory=512m"] 在 devcontainer.json 中无效（VS Code 1.118 及之前版本）。
- 正确做法：改用
docker-compose.yml作为构建入口，在services下写deploy.resources.limits - 示例片段：
deploy:<br> resources:<br> limits:<br> cpus: '1'<br> memory: 512M
- 或者，把资源参数硬编码进
.devcontainer/Dockerfile的ENTRYPOINT，例如：ENTRYPOINT ["docker", "run", "--cpus=1", "--memory=512m", "my-node-app"]——但此法破坏可移植性，仅作临时验证
调试模式下 --inspect=0.0.0.0:9229 会额外吃掉 80~120MB 内存
很多人测出“不调试时 300MB，一 attach 就爆内存”，根源就是 V8 inspector 协议本身要常驻一个独立线程+缓冲区。这不是泄漏，是设计如此。
- 生产环境绝对禁用
--inspect；开发阶段若必须调试，把--max-old-space-size再砍掉 128MB（比如从 256 改成 128） - 用
chrome://inspect连接后，记得点断开连接——V8 不会自动释放 inspector 上下文，持续占用直到进程退出 - 替代方案：改用
node --inspect-brk=0.0.0.0:9229+ VS Codelaunch.json的stopOnEntry: true，让调试器接管后立即暂停，减少空转时间
真正卡住人的不是配置项本身，而是资源限制和 Node 启动参数之间存在隐式耦合：--cpus=1 会让 libuv 线程池默认缩容到 1，此时若代码里有 fs.readFile 大文件或 child_process.exec 同步阻塞操作，整个事件循环就彻底堵死——这时候看 docker stats CPU 是 100%，但 ps aux 里 Node 进程状态却是 S（sleeping），根本查不到热点函数。
