config.json不能放认证凭据，因Composer仅支持auth.json加载凭据；手动添加http-basic等字段会被忽略，导致401错误；凭据必须通过auth.json或COMPOSER_AUTH环境变量配置。
config.json 里为什么不能放认证凭据
Composer 的 config.json 是全局配置文件，用于缓存路径、镜像源、超时等非敏感设置；它**不支持存储 http-basic、github-oauth 或 gitlab-token 等认证凭据**。强行往里面写（比如手动编辑 ~/.composer/config.json 加 "http-basic" 字段），Composer 会忽略这些字段——既不报错，也不生效，徒增维护风险。
常见错误现象：composer install 报 401 Unauthorized，但检查 config.json 看似已填凭据；实际是 Composer 根本没读它，凭据根本没传递出去。
-
config.json只负责配置行为（如cache-dir、fxp-asset插件开关），不是凭据载体 - 认证凭据必须走
auth.json，这是 Composer 唯一正式支持的凭据加载机制 - 哪怕你用
composer config --global http-basic.example.com user pass，它也只会写进auth.json，而非config.json
auth.json 和 config.json 的存放位置与权限差异
auth.json 和 config.json 默认都在 COMPOSER_HOME 目录下（Linux/macOS 是 ~/.composer/），但它们的安全要求完全不同：前者必须严格隔离，后者可适当放宽。
关键区别：
-
config.json权限建议644或600，内容不涉密，即使被读取也无实质风险 -
auth.json必须是600（仅属主可读写），否则 Composer 直接跳过加载——这是硬性校验，不是建议 - 若
~/.composer/目录本身属主为root（比如曾用sudo composer），则auth.json即使设了600也没用，因为当前用户根本打不开该目录
修复命令（复制即用）：sudo chown -R $USER:$USER ~/.composerchmod 700 ~/.composerchmod 600 ~/.composer/auth.json
多仓库凭据冲突：为什么 config --global http-basic 总是覆盖而不是追加
执行 composer config --global http-basic.repo-a.com user1 pass1 再执行 composer config --global http-basic.repo-b.com user2 pass2，结果只有 repo-b.com 的凭据保留——这不是 bug，是设计行为：每次调用都**全量重写 auth.json 中对应域名的条目**，不是 patch 操作。
真实场景中容易踩坑：
- 团队共用同一台机器，A 配了私有 Packagist，B 配了 GitLab，后配的覆盖前配的，导致某人
composer install失败 - CI 流水线里连续运行多个
composer config --global，最后一个生效，其余失效 - 误以为
config.json能“叠加”凭据，试图往里面手工加字段，结果无效
正确做法：直接编辑 auth.json 手动维护多域名结构，或改用 COMPOSER_AUTH 环境变量（注意兼容性，部分自建仓库不支持）。
CI 环境中 auth.json 的生成与清理风险
CI runner 上没有交互终端，也无法复用本地 auth.json，必须动态生成。但很多脚本用 echo '{...}' > ~/.composer/auth.json，这埋了三个雷：
- JSON 格式易出错（少逗号、引号不闭合），导致 Composer 解析失败，报错模糊（常表现为 401 或空响应）
- 默认创建权限是
644，而 Composer 要求600，必须显式chmod 600 - 文件残留：若流水线中途失败，
auth.json可能留在 runner 上，下次构建可能被复用（尤其共享 runner 场景）
推荐写法（GitHub Actions 示例）：composer config --global --auth http-basic.packages.example.com ${{ secrets.USER }} ${{ secrets.TOKEN }}
这条命令自动处理文件创建、权限设置、JSON 格式校验，且失败时会明确报错。
真正容易被忽略的点：CI 中 auth.json 不需要“清理”，因为它是临时 runner 的临时文件；但如果你用 docker run -v 挂载了宿主机 ~/.composer，那凭据就可能跨构建泄露——这种挂载必须禁用。
