直接提升分布式爬虫稳定性需合理配置node.js堆内存：主控进程设2gb–3gb，worker进程设4gb–8gb，代理/聚合服务单独配置，并配合内存监控、并发限制与流式处理。
直接提升分布式爬虫稳定性，关键不是盲目加内存，而是让 Node.js 的堆内存限制与爬虫实际负载匹配。默认 1.4GB 堆限制在高并发、多任务、带解析和代理的爬虫场景下极易触达上限，引发 FATAL ERROR: JavaScript heap out of memory 崩溃。合理配置 --max-old-space-size 标记，是稳定运行的第一道防线。
根据部署模式选择配置方式
分布式爬虫通常由主控节点 + 多个 Worker 进程组成，不同角色对内存需求差异大：
- 主控进程（调度/队列管理）：轻量级，负责分发任务、维护状态，2GB–3GB 足够，避免过度占用影响调度响应
- Worker 进程（实际抓取+解析）：内存消耗主力，尤其在处理大 HTML、执行 DOM 解析（如 Cheerio）、缓存中间结果时，建议设为 4GB–8GB（64 位系统），但需结合单机 CPU 核数和 Worker 数量反推——例如 8 核机器跑 4 个 Worker，总堆上限不宜超过物理内存的 60%
- 代理中转或数据聚合服务：若独立部署，按其实际负载单独配置，不与 Worker 共用同一内存策略
在 package.json 中精准控制启动参数
这是最清晰、可版本化、易协作的方式，特别适合 CI/CD 流水线：
Zenlink - Node SDK for ZenHeart
下载
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
- 为不同角色定义专属脚本：
"scripts": {
"start:worker": "node --max-old-space-size=6144 ./dist/worker.js",
"start:master": "node --max-old-space-size=2048 ./dist/master.js"
} - 配合环境变量进一步细化：
例如NODE_ENV=prod npm run start:worker启动生产 Worker，而开发时用npm run start:worker -- --inspect附加调试，互不干扰 - 避免全局污染：不推荐在
package.json中写死所有环境共用的内存值，应按角色和环境拆分
用 NODE_OPTIONS 实现统一管控（适合容器/集群）
当 Worker 以 Docker 容器或 systemd 服务形式批量部署时，通过环境变量统一注入更高效：
- Docker 启动时指定：
docker run -e NODE_OPTIONS="--max-old-space-size=6144" my-crawler-worker - systemd service 文件中设置：
Environment="NODE_OPTIONS=--max-old-space-size=6144" - 注意：该变量对当前进程及其子进程生效，若 Worker 内部又 fork 新 Node 进程（如子任务隔离），需确保子进程也继承该环境变量
必须同步做的三件事（否则光调内存没用）
仅增大堆限制不能解决根本问题，反而可能掩盖泄漏、拖慢 GC、导致 OOM Killer 杀进程：
-
启用内存监控：在 Worker 启动时加入
--inspect或使用process.memoryUsage()定期上报 RSS/heapUsed，配合 Prometheus 抓取趋势，确认是否真缺内存，还是存在泄漏 -
限制并发连接与队列深度：Node-Crawler 等库的
maxConnections和rateLimit必须与内存配置联动——例如设了 6GB 堆，但开了 100 并发请求，每个请求缓存 20MB 响应体，瞬间就撑爆 -
强制流式处理大响应：禁用
responseType: 'text'全量加载，改用responseType: 'stream'+pipeline或createReadStream边下载边解析，避免 HTML 文本一次性进堆
