因为composer.json会进入Git仓库，凭证可能通过历史提交、CI日志等泄露；必须用auth.json或COMPOSER_AUTH环境变量管理，且需严格权限控制与格式校验。
私有仓库凭证为什么不能写进 composer.json
因为 composer.json 是项目源码的一部分，几乎必然进入 Git 仓库——哪怕你加了注释、用了条件判断，只要文本存在，CI 日志、IDE 快照、历史提交、fork 分支都可能把它翻出来。Git 没有“逻辑删除”，只有“物理存在”。
常见错误现象包括：git diff 里意外暴露 "password": "xxx"；团队成员本地执行 composer config 后忘记清理残留；CI 构建缓存中保留了含凭证的临时 composer.json。
- 永远不要在
composer.json的repositories或config字段里硬编码用户名/密码/TOKEN - 哪怕只写一次、哪怕加了
// TODO: remove before commit，也等于把门钥匙贴在门框上 - 如果已误提交，必须强制重写历史（
git filter-repo），而非仅git rm --cached
auth.json 文件该放哪、怎么管
auth.json 是 Composer 官方支持的凭证存储方式，但它的安全性完全取决于你放哪、谁有权限读它。
推荐路径和权限组合：
全局级（多项目共享）→ 放在 ~/.composer/auth.json，权限设为 600（仅属主可读写）；
项目级（临时调试）→ 放在项目根目录，但必须确保 .gitignore 包含 auth.json，且 CI 脚本不依赖它。
- 检查是否生效：运行
composer config --global --list | grep http-basic，有输出才算加载成功 - 禁止用
composer config http-basic...命令生成项目级auth.json，它默认写入当前目录，极易误提交 - GitLab/GitHub OAuth Token 等长生命周期凭证，建议单独存为
~/.composer/auth.gitlab.json并用COMPOSER_AUTH环境变量注入，避免混入主配置
CI/CD 中 COMPOSER_AUTH 环境变量怎么写才不崩
COMPOSER_AUTH 是 CI 场景下最可控的凭证注入方式，但它对 JSON 格式极其敏感——一个换行、一个多余逗号、一个未转义的双引号，都会让 composer install 静默失败，且不报具体错误。
典型错误现象：composer install 卡住或报 Could not parse authentication config；CI 日志里显示 HTTP 401 但没提示是哪个域名；构建产物里 vendor 缺失私有包。
- 必须是单行、无换行、键名全小写：例如
COMPOSER_AUTH='{"http-basic":{"packages.your-company.com":{"username":"ci","password":"xxx"}}}' - 禁止 shell 变量拼接 JSON 字符串，改用
jq生成：echo '{"http-basic": {"'"$REPO_HOST"'": {"username": "'"$CI_USER"'", "password": "'"$CI_TOKEN"'"}}}' | jq -c - CI 脚本开头加校验：运行
composer config --global --list | grep -q "http-basic"，失败则exit 1
为什么 Nginx/Apache 暴露 /packages 目录比密钥泄露更危险
很多团队花大力气保护凭证，却在 Web 服务配置里留了个 autoindex on，导致整个私有包仓库目录被裸奔——攻击者不用任何凭证，curl https://packages.your-company.com/packages/ 就能下载所有 ZIP 包，反编译出核心业务逻辑。
这不是假设：2025 年某电商公司被竞对挖走支付模块，源头就是 Satis 生成的 /web/packages/ 路径被 Nginx 错误启用了目录索引。
- Nginx 必须禁用 autoindex，并显式拒绝非文件请求：
location / { try_files $uri =404; } - Apache 对应配置：
Options -Indexes+RedirectMatch 404 "^/packages/.*\.zip$" - 额外加固：Satis 构建时启用
"archive": {"skip-dev": true}，避免打包测试代码；同时加--sign生成 GPG 签名，让客户端可验证包完整性
真正危险的不是“密钥有没有泄露”，而是“泄露后有没有第二道防线”——GPG 签名、HTTPS 强制、目录浏览禁用、lock 文件 shasum 校验，这四样缺一不可。少一个，就等于给黑客配了一把万能钥匙的齿痕。
