配镜像源是 composer install 能否成功执行的前提，非可选优化；必须严格满足键名 repo.packagist（单数）、type 值为 composer、url 为 https 且末尾带 /，三者缺一即静默回退官方源，验证需 composer config -g repo.packagist 输出完整 json。
配镜像源不是“可选优化”，是 composer install 能不能跑起来的前提——不配，90% 的国内 PHP 项目会卡在 Loading composer repositories 或直接报 Could not find package。
composer config -g repo.packagist 命令为什么总没反应
它根本没写进去，但 Composer 不报错、不提示，静默 fallback 回 https://packagist.org。三个硬性条件缺一不可：
-
repo.packagist必须是单数键名，写成repos.packagist或repositories.packagist都无效 - 中间的
composer是type值，不是注释或别名，漏掉就等于没配 - URL 必须是 HTTPS 且末尾带
/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致请求/composerpackages.json404）
验证是否真生效：运行 composer config -g repo.packagist，输出必须是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。返回空、null、Key not found 或只有一行 URL 字符串，说明失败。
项目级配置比全局更可靠，尤其在 CI 和宝塔环境
全局配置写在 ~/.composer/config.json，但宝塔用 www 用户、GitHub Actions 用 runner 用户、Docker 容器常以非 root 用户运行——它们读不到你的个人配置。
进项目根目录后执行（注意不加 -g）：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
这条命令会自动在 composer.json 顶层写入 "repositories" 字段，key 固定为 "packagist"：
- 若原
"repositories": {}是对象，它安全追加； - 若原
"repositories": []是数组，它向末尾插入新对象，不覆盖已有私有源； - 绝对不要手动写
"packagist": false，这会关掉基础包校验，导致php、ext-json等必需依赖无法安装。
换源后依然卡住？清缓存和旧文件是硬性步骤
Composer 会优先读取本地缓存和 composer.lock 中记录的旧地址。哪怕你刚配好镜像，它也可能还在往 packagist.org 发请求。
- 先清缓存：
composer clear-cache - 删掉
vendor/和composer.lock - 再执行
composer install（不是update），否则旧 lock 文件里的 hash 可能和镜像元数据不匹配
验证是否真走镜像：运行 composer install -vvv，滚动到底部找日志行，必须出现类似 Reading packages.json from cache at .../https---mirrors-aliyun-com-composer/ —— 如果还看到 https://packagist.org/packages.json，说明没生效。
最容易被忽略的是：改完配置后不删 composer.lock 就直接 install，或者在 CI 流水线里误信全局配置而没做项目级写入——这两处出错，镜像配置等于白配。
