使用环境变量注入令牌可避免硬编码，如在CI/CD中通过${GITLAB_TOKEN}引用加密变量，并动态生成auth.json文件，确保私有仓库访问安全。
在CI/CD环境中使用 Composer 安装私有仓库的包时，需要提供访问令牌（如 GitHub Personal Access Token、GitLab CI Job Token 等），但直接将令牌写入代码或配置文件中会带来严重的安全风险。以下是几种安全存储和使用私有仓库访问令牌的推荐做法。
使用环境变量注入令牌
大多数 CI/CD 平台（如 GitHub Actions、GitLab CI、Bitbucket Pipelines、Jenkins 等）都支持通过加密的环境变量管理敏感信息。Composer 可以通过读取这些变量动态配置认证信息。
在 auth.json 中引用环境变量：
{ "http-basic": { "gitlab.com": { "username": "gitlab-ci-token", "password": "${GITLAB_TOKEN}" } } }然后在 CI 脚本中设置环境变量并运行 Composer：
export GITLAB_TOKEN=$CI_JOB_TOKEN composer install --no-interaction平台如 GitLab CI 中，$CI_JOB_TOKEN 是预定义的临时令牌，具有当前项目的克隆权限，无需额外创建长期 token。
在 CI 中动态生成 auth.json
避免提交包含凭证的 auth.json 到版本控制。应在 CI 运行时动态生成该文件。
示例（GitHub Actions）：
secrets.COMPOSER_TOKEN 是在 GitHub 仓库设置中加密存储的令牌，不会出现在日志中。
使用 SSH 密钥替代令牌（推荐用于 Git）
如果私有包托管在 Git 服务器上，可使用 SSH 部署密钥代替 HTTP 令牌，更安全且易于管理。
步骤：
- 生成专用 SSH 密钥对（如 deploy_key）
- 将公钥添加到私有仓库的“部署密钥”中
- 在 CI 中注入私钥（作为 secret）并配置 SSH agent
Composer 会自动使用 SSH 克隆 git@... 地址的仓库，无需额外配置 http-basic 认证。
最小权限原则与令牌生命周期管理
无论使用哪种方式，都应遵循安全最佳实践：
- 令牌应仅具备下载私有包所需的最低权限（如只读）
- 避免使用个人长期有效的 token，优先使用短期或临时令牌（如 CI_JOB_TOKEN）
- 定期轮换手动创建的 token
- 确保 CI 日志不输出敏感信息（如禁用调试模式）
基本上就这些。关键是不让凭证出现在代码中，利用 CI 平台的加密机制注入，并尽可能使用临时或专用凭证。安全性高，实施也不复杂。
