Composer全局镜像配置失效主因是键名错误、格式不规范及执行用户错位；应优先用项目级配置或显式指定config.json路径，并统一CI中Composer版本。
CI 中 composer config -g repo.packagist 为什么总失效
不是镜像地址问题，而是键名、格式、执行用户三者错一个就静默 fallback 到 packagist.org。Composer 2.2+ 已倾向使用 repositories.packagist.org，而 repo.packagist 在部分 CI 镜像（如 GitHub Actions 的 composer:2.9）中已被标记为软弃用。
常见失效点：
-
repo.packagist写成repos.packagist或packagist.org—— 键名错误，配置写入但 Composer 忽略 - 命令漏掉
composer类型参数：composer config -g repo.packagist https://mirrors.aliyun.com/composer/❌，必须带composer第三个参数 - URL 末尾缺
/，导致parse_url()解析出错，报Invalid argument（尤其在 PHP 8.1+ 上更敏感） - CI runner 以
runner用户运行，但你用sudo composer config -g写进了root的~/.composer/config.json，实际读的是/home/runner/.composer/config.json
Ansible 自动化部署时镜像配置写不进正确位置
根本矛盾在于：Ansible 默认以非登录 shell 执行任务，COMPOSER_HOME 和用户家目录环境变量不可靠，composer config -g 很可能写到 root 家目录，而 PHP worker 进程跑在 www-data 下，压根不读那个文件。
安全做法：
- 不用
-g，改用项目级配置：composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（在working_dir下执行），结果直接落进composer.json，可 Git 提交 - 若必须全局配置，显式指定目标路径：
composer config --global --auth config.json /home/www/.composer/config.json repo.packagist composer https://mirrors.huaweicloud.com/repository/php/composer/ - 配合
community.general.composer模块时，设php_executable和working_dir，避免依赖 PATH；并确认working_dir对运行用户有写权限
多版本 Composer 混用导致 CI 流水线行为不一致
本地是 Composer 2.9，CI 脚本却拉了 composer:1.10 Docker 镜像，同一行 composer config -g repo.packagist 在两边表现完全不同：1.x 完全忽略该键，2.x 正常生效 —— 这不是 bug，是设计差异。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
规避方案：
- CI 脚本开头强制锁定版本：
php composer.phar self-update --2或--1，别用curl | php拉“最新版” - 优先用
repositories.packagist.org键（Composer 2.2+ 支持，且 1.x 会降级兼容为 repositories 数组），写法必须是完整 JSON：composer config -g repositories.packagist.org '{"type": "composer", "url": "https://mirrors.cloud.tencent.com/composer/"}' - 项目级配置天然跨版本：无论 1.x 还是 2.x，
composer config repo.packagist都会正确合并进composer.json的repositories字段
自动探测镜像可用性时 curl -I 返回 403 或 302
华为云、腾讯云等镜像站对未携带 User-Agent 的 curl -I 请求返回 403，阿里云则可能重定向到登录页（302），导致脚本误判源不可用。这不是网络问题，是服务端反爬策略。
探测脚本必须加头：
- 加
-A "composer-ci-probe"绕过 UA 拦截 - 用
-L跟重定向，避免 302 被当失败 - 检查响应体是否含
"packages"字段（而非只看状态码），因为有些镜像返回 200 但内容为空 JSON - 超时设短：
--max-time 5，避免单个源卡住整个 CI 流程
最易被忽略的点：即使探测成功，也得清缓存再写配置，否则 Composer 仍可能读旧 packages.json 快照 —— composer clear-cache 必须放在 config -g 前执行。
