actions/checkout

把 actions/checkout 当成需要固定版本、偶尔重读的基础设施，而不是要评估是否采用的新工具。跨大版本升级值得专门看一眼，因为 v5-v7 改变了 runner 版本要求，也改变了 fork PR 的默认行为。

解决什么问题

工作流在构建、测试或 lint 之前需要仓库文件出现在 $GITHUB_WORKSPACE，但 runner 启动时是空的。加上这个 action 后，代码就会出现在 runner 上，默认只拉取触发工作流的那一个 commit，后续步骤便能对它运行 git 和构建命令。没有它，每个工作流都得自己写 clone 步骤，并自行处理 token、ref 和清理。

有什么不同

除非设置 fetch-depth: 0，否则只拉取触发本次工作流的 commit，这让 job 更快，但依赖完整历史的工具需要相应调整输入。认证由 action 代劳：token 或 SSH key 会被配置好，使需要认证的 git 命令可用，并在 post-job 清理阶段移除。从 v6 起，persist-credentials 把凭据放在 $RUNNER_TEMP 下的单独文件中，而不是直接写进 .git/config；设为 false 则完全不持久化。

影响最大的变化是 v7：当工作流由 pull_request_target 或 workflow_run 触发时，默认拒绝检出 fork PR 的代码，因为这两种触发方式会带着基仓库的 token、secret 和 runner 权限运行。要恢复旧行为，需要在阅读链接中的风险说明后设置 allow-unsafe-pr-checkout: true。这会真正改变工作流行为：依赖在那些触发条件下检出 fork 代码的 job，在调整之前会直接失败。

谁值得试

任何需要在 GitHub Actions 中拿到仓库内容的人都可以用，它通常是工作流的第一步。使用 pull_request_target 或 workflow_run 的维护者应把 v7 升级当作一次审查事项，因为新的默认值可能让原本能跑的 fork 检出 job 停下。在 Docker 容器 action 里执行需认证 git 命令的团队，要确认 runner 版本，v6 要求 Actions Runner v2.329.0 或更高。想改这个 action 本身的人则不行：README 明确表示目前不接受贡献。

使用条件与边界

最需要确认的是版本兼容性。v5 的 node24 运行时要求 runner v2.327.1 或更高；v6 把凭据放到单独文件后，Docker 容器 action 内的认证 git 命令要求 runner v2.329.0 或更高。自托管 runner 若停留在旧版本，升级后可能出问题。

日常使用上，token 默认会写入本地 git 配置，使脚本可以 push，并在 post-job 清理时移除；如果 job 不应拥有该权限，就设 persist-credentials: false。需要完整历史的工作流必须设 fetch-depth: 0，在大仓库上会增加耗时。变更记录见发布页，fork 检出的取舍见GitHub 的说明。

HotRepo 点评

HotRepo 在 2026-10-24 记录到 8,966 星，2026-10-25 记录到 8,967 星，这两天各增加 4 星；样本太短，无法判断趋势。升级前真正值得确认的是：你的工作流是否在 pull_request_target 或 workflow_run 下检出 fork 代码，以及 runner 是否满足 v5/v6 的最低版本。