Node Worker 设置 32 MB 仍用上大堆：检查进程的堆参数

给 Worker 配了 resourceLimits: { maxOldGenerationSizeMb: 32 }，任务却仍能使用远大于 32 MB 的堆。若主进程启动时有 --max-old-space-size=1024，先查这个参数，而不是继续减小 Worker 配置。

Node.js 24.21.0 中可见这一情况，24.22.1 的正式文档也明确规定：命令行的 --max-old-space-size 覆盖 maxOldGenerationSizeMb；--max-semi-space-size 对年轻代限制有对应优先级。

配置里写了什么，与 V8 实际采用什么是两件事

worker.resourceLimits 可以回显构造时的限制，不应单凭这个对象断言实际堆上限已经生效。检查启动脚本、服务管理器和容器入口中的 Node 参数，也检查部署环境是否通过 NODE_OPTIONS 注入了堆配置。

需要观测时，在现有 Worker 的诊断入口读取 V8 堆信息：

import v8 from 'node:v8';

const heapLimit = v8.getHeapStatistics().heap_size_limit;

值的单位是字节。它反映堆上限，不能要求其精确等于配置的 32 MiB，也不能把它当作 Worker 的 RSS。诊断应随原任务记录，不要为了检查主动把生产任务推到内存耗尽。

需要按 Worker 限堆时，先消除进程级覆盖条件

如果主线程不必依赖统一的堆参数，可在受控环境评估从启动配置中撤去冲突参数，然后保留每个 Worker 的 resourceLimits。调整前记录主线程原有负载和内存需求；撤去参数也会改变主线程可用堆，不能只看 Worker 一侧恢复就上线。

不要尝试给 Worker 的 execArgv 塞入不同的 --max-old-space-size。Worker 构造器不支持在该选项中传入这类 V8 参数。把 execArgv 清成空数组，也不能据此保证抹掉已经作用于进程的 V8 设置。

若主线程必须保留一套堆参数，而高风险任务必须有另一套，可评估改为独立 Node 子进程，并为子进程显式提供所需启动参数及环境。要一并迁移通信、失败处理、超时和回收流程；仅从 Worker 换成子进程，不会自动形成操作系统级总内存配额。

验收要覆盖线程失败和主进程存活

Worker 的 resourceLimits 约束 JavaScript 引擎资源，不涵盖 ArrayBuffer 等外部数据，进程遇到全局内存耗尽仍可能退出。若需求是限制任务对整台服务的影响，还需按部署环境配置独立进程或容器的内存边界。

在隔离环境使用原任务检查实际堆信息、正常结果、错误事件与任务清理，再核对主线程正常请求。不要把成功创建 Worker 当作限额验收，也不要依赖一次未超限运行证明所有内存都受控。回退时恢复原启动配置和任务入口，保留可定位覆盖条件的版本与参数记录。