全局配置仅适用于单人本地开发，ci/cd、docker、宝塔等环境因用户隔离导致其失效；项目级配置更可靠，需执行composer config repo.packagist composer https://mirrors.aliyun.com/composer/并删除vendor与composer.lock后install。
全局配置只适合单人本地开发
敏捷开发强调协作和环境一致性，全局配置 composer config -g repo.packagist 看似省事，但实际在 CI/CD、Docker、宝塔或多人共享服务器上会彻底失效——因为它的配置只写进当前用户的 ~/.composer/config.json，而 GitHub Actions 用 runner 用户、宝塔用 www 用户、Docker 容器里甚至没有你的家目录。
常见现象：composer install 在本地快如闪电，推到 GitLab CI 就卡在 Loading composer repositories，日志里全是 packagist.org 的请求地址。
- CI 脚本里别依赖全局配置，直接加
--repository-url=https://mirrors.aliyun.com/composer/ - 宝塔部署前先确认执行用户：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 团队项目根目录下应避免出现空
"repositories": []，否则composer config repo.packagist会报错并中断流程
项目级配置必须用命令写入，不能手改 composer.json
手动往 composer.json 里硬编码 "repositories" 字段，看似可控，实则埋雷：Composer 会合并而非覆盖依赖包自带的源声明，导致同时向阿里云、腾讯云、私有源发请求，反而更慢；且不同成员提交的格式不一致（比如有的写 https://，有的漏斜杠），引发 lock 文件冲突。
正确做法是进项目根目录后运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
这条命令会自动在 composer.json 顶层插入或更新 "repositories" 对象，key 固定为 "packagist"，不会清空已有私有源，也不破坏 JSON 结构。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 如果项目已有
"repositories": {}，命令能安全追加；如果是"repositories": []，需先手动改成空对象再执行 - 改完必须删掉
vendor/和composer.lock，再跑composer install——update会沿用旧 lock 中的元数据地址，照样走官方源 - 该配置会被 Git 跟踪，协作者拉代码后无需额外操作，开箱即用
验证镜像是否真生效，只看这一行输出
别信“我敲过命令了”，composer config -g repo.packagist 静默失败是常态。真正有效的判断依据只有一条：
运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，形如：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。任何其他结果——空、null、https://packagist.org、或报 Key not found——都说明没写进去。
- 最常见错误：把
repo.packagist写成repos.packagist（多一个 s）或packagist.org - 漏掉中间的
composer参数，命令变成composer config -g repo.packagist https://...，Composer 直接忽略整行 - URL 少了末尾斜杠，例如
https://mirrors.aliyun.com/composer，部分 Composer 2.2+ 版本会拼出/composerpackages.json导致 404
composer install 还卡？问题大概率不在镜像
镜像只加速包下载环节，不参与依赖解析。如果你发现卡在 Resolving dependencies 或 Writing lock file，换任何镜像都没用。
典型诱因包括：
-
"php": "^7.4 || ^8.0"这类宽泛约束，让 Composer 尝试数百种版本组合 -
require-dev里用了未锁定的"phpunit/phpunit": "^10.0"，每次都要重新解析兼容性 - 大量
dev-main分支依赖，触发实时元数据抓取
这类问题必须收紧版本约束、移除非必要 dev 包、用 composer update --lock 锁定解析结果，而不是反复折腾镜像地址。
