摘要：2026 年 9 月 23 日，GitHub 发布 Node 20 退役的最终通知。Actions 运行器现在统一用 Node 24 执行 JavaScript action，此前的临时逃生开关 ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION 也已经下线。Action 维护者需要把 runs.using 改成 node24 并发布新版本；同时 Node 24 与 macOS 13.4 及更早版本不兼容、官方不支持 ARM32，使用这些系统或架构的自托管运行器不再被支持。
这不是一次预告，而是一次收尾。GitHub 在公告里把它称为该主题的「最终通知」——从 2025 年 9 月 19 日第一次宣布，到 2026 年 9 月 23 日逃生开关被撤掉，中间留给生态的迁移时间已经走完。
对绝大多数只写工作流、不写 action 的人来说，这件事可能已经在你不知情的时候完成了：GitHub 说明所有第一方 action 的最新版本都已经迁移到 Node 24。真正被卡住的，是自己维护 JavaScript action 的团队，以及在旧系统上跑自托管运行器的团队。下面把需要动手的三类人分开说清楚。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
发生了什么：运行器改用 Node 24，逃生开关被移除
公告给出的事实只有两条，但每条都带后果。第一条：运行器现在用 Node 24 来跑 JavaScript action。也就是说，一个在 metadata 里声明 runs.using: node20 的 action，不再有 Node 20 可以运行。第二条：临时的 ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION 开关不再可用——过去在过渡期里，团队可以靠设置这个环境变量让运行器继续用旧版 Node，现在这条退路被堵上了。
覆盖范围包括 github.com 与 GitHub with Data Residency，也就是托管的两侧都生效。公告同时提示，最新版本的所有第一方 action 已经完成迁移，所以还在报错的通常是第三方 action 或企业内部自研 action 的旧版本。
一个具体场景：自研 action 的工作流突然报错
设想一个团队维护着内部 action my-org/deploy-helper，它把部署逻辑包成 JavaScript action，metadata 里写着 runs.using: node20。这个 action 三年来一直很正常，团队的工作流里引用的是 v1 这个 tag，从来没想过要动它。
退役生效后，引用这个 action 的所有工作流会在执行到它时失败。团队面对两个约束：一是必须把 runs.using 改成 node24 并发布一个新版本，二是改完之后可能还要处理 Node 20 到 Node 24 之间运行时行为差异带来的兼容问题——公告没有承诺这段升级是零成本的，它只给了迁移方向。如果这个团队过去一直依赖那个环境变量开关维持运转，现在连临时缓解都没有，只能改代码。
更麻烦的一类情况在自托管运行器上。公告明确写出：Node 24 与 macOS 13.4 及更早版本不兼容，并且不官方支持 ARM32。因此，使用这些操作系统或架构的自托管运行器已经不再被支持。这类环境往往出现在嵌入式构建机或老旧的 CI 机器上，升级运行器镜像并不总是团队自己能决定的事。
为什么这会改变工作流
这类运行时退役的代价，从来不落在「改一行」上，而落在验证成本上。把 runs.using 从 node20 改成 node24 是几十秒的事，真正花时间的是确认依赖树的原生模块、Node 内置 API 的行为差异、以及那些依赖具体 Node 版本特性的边界代码。对维护着十几个内部 action 的平台团队来说，这是一次小型集中升级。
第二个变化是依赖来源的收紧。过去绕不过去的旧 action，可以用环境变量换时间；现在这条时间买不到了。这会逼迫团队做一件长期被推迟的事：盘点工作流里引用的每一个第三方 action，确认它的最新版本是否已支持 Node 24，把 pins 从旧 tag 或旧 SHA 更新上去。这件事对供应链安全其实也是好事——未维护的第三方 action 会在这轮里被暴露出来。
第三个变化体现在自托管场景的选型上。ARM32 与老 macOS 被排除，意味着一些边缘构建环境的升级路径不再由 GitHub 提供，团队需要自己规划：是换架构、换系统版本，还是把这类构建迁到 GitHub 托管的运行器上。
限制、边界与人应该在哪儿接手
公告没有给出具体的报错文案，也没有提供兼容层或宽限窗口。这一点需要团队自己处理：报错可能出现在 action 加载阶段，也可能表现为运行时异常，值班的人需要能分辨「这是 Node 版本问题」还是「这是我自己的逻辑问题」。建议把 action 版本升级作为一个独立批次合并，而不是夹在一个功能 PR 里，这样一旦流水线整体变红，能立刻定位到原因。
另一条边界是第三方 action 的响应速度不由你决定。如果某个关键第三方 action 的维护者没有发布 Node 24 版本，你只能选择更换实现、把逻辑内联进自己的仓库，或者接受这条流水线不可用。人的接管点就在这里：在截止日期前完成依赖清点，而不是等流水线红了再逐个排查。
如何迁移
Action 维护者：打开 action.yml，把 runs.using 的值改为 node24，本地用 Node 24 跑一遍 action 的测试，然后发布新版本并在 release notes 里写明这是必须升级的版本。
工作流作者：逐个检查工作流里引用的 JavaScript action，升级到已支持 Node 24 的最新版本；对锁定到具体 SHA 的引用，需要重新取一次新版本的提交哈希。
自托管运行器管理员：核对运行器的操作系统与架构，确认不落在 macOS 13.4 及更早版本或 ARM32 上；如已在范围内，需要先升级运行器环境，再恢复作业。
信息来源
- GitHub Changelog：Node 20 is no longer available in GitHub Actions（2026-09-23，Retired）— https://github.blog/changelog/2026-09-23-node-20-is-no-longer-available-in-github-actions
- GitHub Docs：Metadata syntax for GitHub Actions（runs.using / runs-for-javascript-actions）
- GitHub Docs：Versions for actions（第一方 action 的 Node 24 迁移状态）
HiFox ：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 Hifox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。