解读

在国内 PHP 面试中，面试官提到“Action 版本锁定策略”时，通常不是指 PHP 语言本身的特性，而是指在持续集成/持续部署（CI/CD）流水线里，对 GitHub Action（或 GitLab CI、Gitee Go 等国内等价服务）中引用的第三方 Action 进行版本锁定，防止因为上游作者发布破坏性更新而导致线上构建或部署失败。PHP 项目普遍依赖 Composer 锁版本，但 CI/CD 脚本里的 Action 版本却经常被忽略，成为“最后一公里”的稳定性盲区。面试官想考察的是候选人是否具备“端到端稳定性”意识，能否把 Composer 的锁版本思维延伸到 DevOps 环节，并给出可落地的中国境内网络优化方案。

知识点

1. GitHub Action 版本引用方式：分支、语义化标签、commit SHA。
2. 国内镜像源与网络加速：actions 目录缓存、ghproxy.com、fastgit.org、自建 Nexus 代理。
3. 哈希锁定（SHA256）与不可变基础设施理念。
4. PHP 项目 CI 常见步骤：composer install、phpunit、phpstan、sonarqube、docker build、kubectl rollout。
5. 锁定策略的分级：开发分支可用语义化小版本，主干分支必须锁定 commit SHA。
6. 自动化更新工具：dependabot、renovate，以及国内私有化部署方案。
7. 合规审计：国内等保 2.0 要求“可控、可追溯”，锁定 SHA 可作为变更审计证据。

答案

我团队在 PHP 微服务仓库里采用“三级锁定”策略：

1. 语法层面：所有 .github/workflows/*.yml 文件中，凡引用外部 Action，一律使用 40 位 commit SHA，例如 actions/checkout@1e31de5234b9f8995739874a3079edc3fb180db6，并在注释里写明对应的语义化标签，方便后人识别。
2. 网络层面：由于 GitHub 在国内存在间歇性超时，我们在自建的 GitLab Runner 里预拉取常用 Action 到内网 Nexus 代理，CI 脚本中把 https://github.com 替换为 https://nexus.xxx.com/github-proxy，实现“源站不可达时 30 秒内自动回退”的兜底。
3. 更新层面：私有化部署的 Renovate 每周扫描一次，自动生成“Action 版本升级 Merge Request”，MR 通过后会触发灰度流水线，跑一遍 PHPUnit、PHPStan、接口自动化测试，全部通过才合并到 main 分支；合并后再次触发镜像构建与 Kubernetes 滚动发布，实现“锁定—升级—验证—发布”闭环。

通过这套策略，过去一年我们 PHP 项目的 CI 失败率从 3.2% 降到 0.15%，且完全符合公司内审“变更可追溯”要求。

拓展思考

如果公司全面搬到 Gitee 或 Coding.net，GitHub Action 无法直接使用，可以把锁定策略平移到 Gitee Go 的「插件市场」或 Coding 的「自定义插件」。此时需要：

1. 将原 Action 用 PHP 或 Go 重写为容器化插件，版本号用 Git Tag 管理；
2. 在 .workflow 文件中同样使用 commit SHA 锁定插件镜像；
3. 把 Nexus 代理换成 Harbor 镜像仓库，开启镜像签名与不可变策略，确保“插件镜像被锁定后任何人无法覆盖”。

这样就把“Action 版本锁定”从 GitHub 生态无缝迁移到国内代码平台，同时保持与 PHP Composer 锁文件一致的“可重复、可审计、可回滚”理念。