Composer不支持自动故障切换，config -g repo.packagist失效主因是键名错（如repos.packagist）、漏composer类型参数、URL末尾缺/，三者任一出错即静默回退官方源；验证须看config -g输出是否为完整JSON、diagnose中Repo域名匹配、-vvv日志请求URL正确。
composer config -g repo.packagist 命令为什么没生效
大概率是三个硬性条件漏掉一个：键名写成 repos.packagist（多了一个 s）、漏掉 composer 这个 type 值、URL 末尾没加斜杠 /。这三处任一出错，Composer 2.x 都会静默 fallback 到官方源，不报错也不提示。
验证是否写入成功，直接运行：composer config -g repo.packagist
输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON 对象。空、null、报错或只返回 URL 字符串（新版行为），都说明配置失败。
-
repo.packagist是固定键名，不能写成packagist.org或repositories.packagist -
composer是 type 值，不是可选参数，必须显式写出 - URL 必须是 HTTPS，且末尾带
/，例如https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌ - Windows 用户配置文件路径在
C:\Users\用户名\AppData\Roaming\Composer\config.json，别手写，用命令写入更安全
项目级配置怎么避免覆盖私有仓库
项目已有 repositories 字段时，手动编辑 composer.json 极易出错——漏方括号、引号不全、误删已有源。正确做法是让 Composer 自动合并：
进项目根目录，执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/
（注意：不加 -g）
- 如果
composer.json原本是"repositories": {}，命令会转为标准数组格式并追加 packagist 条目 - 如果原本是
"repositories": [ ... ]，命令会向数组末尾插入新项，不破坏原有私有源 - 千万别写
"packagist": false，这会导致基础包（如php、ext-json）校验失败 - 改完后运行
composer update --lock，确保composer.lock记录新源地址
宝塔/CI 环境里全局配置为啥不起作用
全局配置写在 /root/.composer/config.json，但它只对 root 用户生效。宝塔「一键部署」、PHP 管理器、计划任务默认以 www 用户运行，根本读不到 root 的配置。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
解决方法很直接：先确认实际执行用户（比如 whoami 或查日志 UID），再针对性配置：
- 给
www用户配：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本中，确保
composer config -g和后续composer install在同一用户上下文执行 - 临时方案：所有命令加
--repository-url=...参数，它优先级最高，能绕过用户权限问题 - 别指望
sudo composer config -g后普通用户自动继承——Composer 不共享跨用户配置
换源后还是卡在 Resolving dependencies 怎么办
镜像只加速下载（Downloading 阶段），对 Resolving dependencies 阶段完全无效。这个阶段卡住，和镜像无关，是本地解析逻辑的问题。
常见诱因：
-
composer.json里 PHP 版本约束太宽，比如"php": "^7.4 || ^8.0 || ^8.1"，导致版本组合爆炸 -
require-dev里塞了大量未锁定版本的工具包（如phpunit/phpunit、friendsofphp/php-cs-fixer） -
config.platform.php没设或设错，与当前 PHP 版本不一致，触发大量兼容性重算 - 项目用了已废弃的
fxp/composer-asset-plugin，它额外请求 Bower/NPM 源（这些源没国内镜像）
此时换镜像毫无帮助，得看 composer diagnose 输出，或加 -vvv 观察解析过程中的冲突点。
