act：把 GitHub Actions 搬回本地跑，值不值得用？
在本地运行 GitHub Actions 🚀
秒懂
- 它是什么？
- act 是一个用 Go 写的命令行工具，让你在本地运行 GitHub Actions 工作流。本文基于其 README 和仓库信息，分析它的工作原理、安装方式、适用场景和局限。
- 适合谁用？
- act 适合两类人：一是频繁修改 .github/workflows 文件、苦于每次都要 push 才能验证的开发者，二是想用 GitHub Actions 语法替代 Makefile 做本地任务编排的人。不适合的是那些工作流重度依赖 GitHub 特有服务（如 secrets 管理、特定 runner 镜像、托管服务）的团队，因为本地环境无法完全模拟这些。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 37 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
为什么要把 GitHub Actions 拉到本地？
GitHub Actions 的常规开发流程是：改完 .github/workflows 里的文件，提交，推送，然后等云端 runner 跑完，再看日志。这个过程慢，而且每次都要污染仓库历史。act 解决的就是这个痛点。它让你在本地直接执行工作流，获得快速反馈。README 里明确说了两个动机：一是快速反馈，不用每次 commit/push 就能测试工作流改动；二是把 act 当本地任务运行器，替代 Makefile。后一个用途有点出人意料，但确实合理。GitHub Actions 的语法比 Makefile 更结构化，有现成的条件判断、矩阵构建和缓存机制。对于已经熟悉 Actions 的团队，用同一套语法管本地任务，省去学习两套工具的成本。
act 的工作原理：Docker 容器模拟 runner
act 的运行机制在 README 里有清晰描述。它读取 .github/workflows/ 下的文件，确定需要执行哪些 action。然后通过 Docker API 拉取或构建所需镜像，根据工作流里定义的依赖关系计算出执行路径。最后用 Docker API 为每个 action 启动容器，并配置与 GitHub 托管 runner 一致的环境变量和文件系统。这个设计的关键在于：它不模拟 GitHub 的整个后端，只模拟 runner 的容器环境。所以工作流里用到的 service container、缓存、artifact 上传等，act 都依赖 Docker 来实现。这也意味着，没有 Docker 环境就无法使用 act。另外，act 使用的镜像需要与 GitHub 的 runner 镜像保持兼容，如果工作流里用了特定版本的 runner 镜像，act 可能无法完全匹配。
安装与基本用法
act 的安装方式在 README 里没有详细说明，但仓库主页指向了用户指南（nektosact.com）。从仓库布局看，act 是 Go 项目，支持从源码构建。README 给出了手动构建的步骤：先安装 Go 1.20+，然后 git clone git@github.com:nektos/act.git，运行 make test 做单元测试，最后 make install 安装。对于不熟悉 Go 的用户，更简单的方式是下载预编译的二进制，但 README 没有提供具体命令。实际使用时，你只需要在项目根目录运行 act，它会自动读取 .github/workflows/ 下的文件。如果想运行特定工作流，可以指定文件名或 job 名称。act 还支持通过 -s 参数传递 secrets，用 -G 覆盖环境变量。这些细节需要查阅用户指南，README 没有展开。
本地测试的边界：哪些能跑，哪些会失真
act 的本地模拟并不完美。README 提到环境变量和文件系统会配置成与 GitHub 一致，但这是针对标准 runner 镜像而言。如果你的工作流依赖 GitHub 特有的服务，比如 secrets 管理、部署密钥、oidc 令牌，act 可能无法完全模拟。另外，GitHub 托管的 runner 有大量预装软件，act 使用的镜像可能没有这些。这意味着一个在云端跑得好好的工作流，在本地可能因为缺少某个工具而失败。act 的文档里也提到，某些 action 可能依赖特定的 runner 架构或网络环境，本地跑起来行为会不同。这不是 act 的缺陷，而是本地模拟的固有局限。你需要明确，act 的目标是快速验证语法和逻辑，而不是保证与云端行为完全一致。
一个真实的替代方案：GitHub 官方 runner
如果你需要更接近生产环境的本地测试，可以考虑使用 GitHub 自托管 runner。GitHub 官方提供了自托管 runner 的安装脚本，你可以在自己的机器上运行一个 runner 服务，它连接到 GitHub 并执行工作流。与 act 的区别在于：自托管 runner 是真正运行在 GitHub 的调度之下，使用相同的 runner 软件，因此环境一致性更高。但它的缺点是：你需要为每个仓库或组织配置 runner，而且工作流执行仍然需要触发，无法像 act 那样在本地直接运行。act 的优势是即改即跑，不依赖网络和 GitHub 服务。自托管 runner 的优势是环境更真实，但设置和维护成本也更高。对于大多数开发者，act 的快速反馈已经足够。
维护与升级成本
act 的发布节奏很稳定，从仓库信息看，v0.2.89 于 2026 年 6 月发布，v0.2.88 在 5 月，v0.2.87 在 4 月，基本每月一个版本。这意味着项目在持续维护，但频繁的版本更新也带来升级成本。GitHub Actions 本身在快速发展，新的语法和 action 不断出现，act 需要跟上这些变化。每次升级 act 都可能引入行为变化，你需要重新验证工作流。另外，act 的许可证是 MIT，这意味着你可以自由使用和修改，但如果你修改了代码并分发，需要保留版权声明。对于企业用户，MIT 许可证没有传染性，可以安全集成到商业产品中。但要注意，act 依赖 Docker，而 Docker 本身的许可证和版本也可能影响你的部署环境。
谁应该用，谁应该避开
如果你是一个前端或后端开发者，经常调整 CI 流程，act 能显著减少调试时间。它特别适合那些工作流简单、不依赖复杂云服务的项目。对于开源项目维护者，act 也可以作为本地测试工具，避免每次 push 到 CI 才发现错误。但如果你维护的是大型 monorepo，工作流涉及多个服务、矩阵策略和大量缓存，act 可能无法提供足够的性能，因为每个 action 都要启动 Docker 容器，开销不小。另外，如果你的团队习惯用 GitHub Actions 的 marketplace action，有些 action 可能不支持本地运行，这需要你逐个验证。act 不是 GitHub 官方工具，它是一个社区项目，所以遇到问题时只能靠 GitHub discussions 求助。如果你需要企业级支持，可能需要考虑商业 CI 工具或者官方 runner。
编辑结论
act 适合两类人：一是频繁修改 .github/workflows 文件、苦于每次都要 push 才能验证的开发者，二是想用 GitHub Actions 语法替代 Makefile 做本地任务编排的人。不适合的是那些工作流重度依赖 GitHub 特有服务（如 secrets 管理、特定 runner 镜像、托管服务）的团队，因为本地环境无法完全模拟这些。采用前先验证三件事：你的 Docker 环境是否可用，工作流中使用的 action 是否支持本地运行，以及 secrets 和文件系统挂载是否符合预期。act 的 MIT 许可证和活跃的发布节奏（v0.2.89 于 2026 年 6 月发布）表明它处于持续维护中，但 GitHub Actions 本身更新频繁，act 的兼容性需要逐版本验证。最终判断：如果只是调试工作流语法，act 值得一试；如果追求生产级一致，它只能是辅助工具。
社区笔记