Actions 报 Can't store NODE_OPTIONS using GITHUB_ENV

构建步骤还没启动，前一个设置变量的步骤就报 Can't store NODE_OPTIONS output parameter using '$GITHUB_ENV' command.。文件里明明是合法的 NODE_OPTIONS=... 单行文本，换引号或改成多行格式也没有用：Runner 明确禁止通过 GITHUB_ENV 设置这个变量。

这里处理的是 Actions 环境文件限制。它不表示 Node.js 不能读取 NODE_OPTIONS，也不表示工作流中的每个 env 位置都禁止该变量。当前 Runner 2.338.0 仍有这项拦截，变量名的大小写变化不会绕过检查。

把已审核的选项放到实际构建步骤

先找到写入 GITHUB_ENV 的那一步，以及真正启动 Node 的构建步骤。保存工作流配置后，删除前者对 NODE_OPTIONS 的写入，保留其他确实需要传递的变量。然后在消费者的步骤 env 中设置已确认适用的选项：

- name: Build project
  env:
    NODE_OPTIONS: --max-old-space-size=2048
  run: npm run build

这是已有 Node 构建任务中的步骤片段，要求项目已经完成 checkout、安装正确的 Node 和锁定的依赖，并确实有 build 脚本。2048 只是配置示例，应按现有构建需求和机器预算调整。堆上限不等于整个进程或容器的内存上限，不能用它证明不会被 OOM 杀掉。

步骤级 env 在该步骤执行期间覆盖同名 job 或 workflow 变量。仅有一个构建步骤需要的选项，就限定在那里，避免把预加载或运行参数带给其他 Node action。这个变量也可能被该步骤启动的 Node 子进程继承，仍要核对整个构建调用链。

有效文本也会被变量名策略拒绝

GITHUB_ENV 的普通格式错误与这条错误不同。一个含换行的值没有使用多行协议，会产生 Invalid format；NODE_OPTIONS 则可以已经通过文本解析，随后被变量名拦截。

因此，下面这些改写都不能解决这项限制：给值再加引号、用脚本动态拼出值、使用 heredoc、多换一个大小写形式。不要为了让文件写入成功去降级 Runner 或修改它的安全检查。若其他多行变量还需要环境文件，按它们自己的协议处理，不要一起删掉。

动态值还要审查来源

确有可信步骤需要计算选项时，可以先用中性的 output 名保存结果，再在后续 Node 步骤映射到 env。生产者必须正确写入输出协议，消费者应检查参数是否属于项目允许的值；换了变量名并不会把不可信输入变成可信配置。

尤其要留意 -r、--require、--import 和 loader 一类选项，它们能够加载代码。不能直接把 PR 内容、外部参数或未经审核的模块路径传进有凭据的构建步骤。需要预加载的模块，应确认代码、依赖和来源都属于这次任务允许执行的范围。

固定选项可以直接写在步骤配置中，无需专门多开一个 job 来生成同样的常量。已有复用工作流则要同时核对 input 契约和最终消费者，不能只在调用端设置变量，就认为被调用的 Node 已经收到。

Runner 放行之后，还要检查 Node 本身

Node.js 对 NODE_OPTIONS 有自己的允许选项列表。允许在 Actions 的步骤 env 中定义变量，不代表所装 Node 接受里面的每个参数。比如 Node 24.10.0 不允许把 -p 或脚本文件本身放进这个变量，遇到不支持的内容会退出。

使用的 Node 版本、实际启动命令和参数优先关系要一起检查。命令行的单值选项可以覆盖同名环境选项；允许重复的选项则可能叠加，不能只看工作流里的一行就判断最终状态。

在原构建入口确认目标 Node 进程取得预期选项，再看构建和已有测试是否完成。设置变量步骤不再报错，只证明环境文件限制已避开；构建仍可能因依赖、内存或业务错误失败。撤回时恢复原步骤配置和参数传递方式，保留其他必要环境键，避免留下一个旧 writer 再次写入被禁变量。