composer怎么在GitHub Actions使用_CI环境配置composer方法-composer-PHP中文网

GitHub Actions 中 composer install 报“Could not authenticate against github.com”是因默认环境未将 GITHUB_TOKEN 注入 Git 凭据系统，需改用 HTTPS URL 并配置 git config --global url."https://x-access-token:${{ secrets.GITHUB_TOKEN }}@github.com/".insteadOf "https://github.com/"，同时加 --no-interaction 和 --prefer-dist，缓存 ~/.composer/cache 而非 vendor/，并显式指定匹配的 PHP 版本。

composer怎么在github actions使用_ci环境配置composer方法

GitHub Actions 里 `composer install` 报错 “Could not authenticate against github.com”

这是最常见问题：Actions 默认不带 GitHub 的 SSH 或 token 权限去拉私有包（包括你自己的 private repo 作为依赖），composer install 卡在认证环节。

根本原因不是 Composer 本身，而是 GitHub Actions 的默认环境没把 GITHUB_TOKEN 注入到 Composer 的 Git 凭据系统里。Composer 用 Git 协议克隆时，会尝试走 HTTPS + 凭据，而 GITHUB_TOKEN 并不会自动填进去。

在 composer.json 中避免用 git@github.com:user/repo.git 这种 SSH 地址；改用 https://github.com/user/repo.git

在 workflow 文件里，运行 composer install 前加一步配置 Git 凭据：

git config --global url."https://x-access-token:${{ secrets.GITHUB_TOKEN }}@github.com/".insteadOf "https://github.com/"

确保 workflow 使用的 runner 是 Ubuntu（其他系统如 macOS 的 Git 配置路径可能不同，容易漏）

要不要加 `--no-interaction` 和 `--prefer-dist`？

要，而且必须加。CI 环境没有交互终端，不加 --no-interaction 会让 composer install 卡住等输入；不加 --prefer-dist 可能触发源码安装（--prefer-source），拉取大量 .git 数据，慢且易失败。

Gitguard Skill

Git 安全扫描与仓库健康审计 — 基于熵的密钥检测、复合健康评分、提交质量分析、陈旧分支清理以及依赖扫描

下载

--no-interaction 是安全底线，不加可能让 job 挂起超时
--prefer-dist 能显著提速，尤其对含大量 vendor 的项目；它优先用 packagist 提供的 zip 包，而非 git clone
如果项目依赖了未打包进 packagist 的私有库，且你已配好 Git 凭据，--prefer-dist 仍可用 —— Composer 会 fallback 到 zip 下载（只要该 repo 启用了 GitHub Releases 或支持 archive URL）

缓存 `vendor/` 目录有没有必要？

有必要，但别直接缓存整个 vendor/。Composer 自带的 composer install 已经做了大量优化，真正值得缓存的是 Composer 的全局 cache 目录（~/.composer/cache），它存着下载过的 zip、dist 包和已解析的 lock 文件元数据。

用 actions/cache@v4 缓存 ~/.composer/cache，key 推荐包含 composer.lock 的 hash：
```
key: composer-${{ hashFiles('**/composer.lock') }}
```
不要缓存 vendor/：不同 PHP 版本、扩展差异会导致缓存失效或运行时错误；而且 composer install --prefer-dist 本身很快，收益远不如缓存 Composer 自身 cache
注意：缓存 action 必须在 composer install 步骤之前执行，否则没机会命中

PHP 版本不一致导致 `composer install` 失败

本地开发用 PHP 8.2，CI 里默认是 PHP 8.0？Composer 会检查 platform 配置或当前 PHP 版本是否满足 require.php 约束，不匹配就报错“Your requirements could not be resolved”。

在 workflow 中显式指定 PHP 版本，例如用 shivammathur/setup-php@v2，并设 php-version: '8.2'
检查 composer.json 的 config.platform.php 是否硬编码了版本（比如 "7.4"），这会让 Composer 强制按该版本解析依赖，忽略实际环境 —— CI 里若 PHP 更高，反而可能错过兼容性检查
运行 composer show php 可确认当前环境识别出的 PHP 版本，比看 workflow 日志更准

缓存逻辑和凭据注入这两步最容易被跳过，一漏就全链路失败；尤其是私有包场景下，光配对 GITHUB_TOKEN 还不够，Git URL 重写那行命令少一个斜杠都会失效。