镜像仅加速包下载而非打包，composer卡在downloading阶段因直连github慢，需删composer.lock和vendor后重装并验证镜像url；resolving dependencies卡住与镜像无关，主因内存不足或xdebug启用。
镜像本身不提升打包速度，只加速包下载；真正卡在“打包”环节的，基本不是镜像能解决的问题。
为什么composer install卡在Downloading阶段？
这是镜像能起作用的典型场景：Composer 正在从 GitHub 下载 zip 包，但默认走 https://codeload.github.com/ 或 https://api.github.com/，国内直连极慢甚至超时。
- 现象：日志里反复出现
Downloading https://codeload.github.com/...，单个包耗时 >10 秒 - 原因：镜像只代理元数据（包名、版本、依赖关系），不托管实际 zip 文件
- 关键点：换源后必须删掉
composer.lock和vendor/，再跑composer install，否则旧dist.url仍指向 GitHub - 验证方式：加
-vvv运行，看下载域名是否变成mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn
Resolving dependencies 卡住和镜像无关
这个阶段完全本地计算，不发网络请求。镜像再快也救不了——它根本没参与。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 常见诱因：
memory_limit过低（如 128M）、启用了xdebug、"php": "^7.4 || ^8.0"这类宽泛约束 - 项目里存在未锁定的
dev-分支依赖，或composer.lock残留已下线包的引用 - 临时解法：
COMPOSER_MEMORY_LIMIT=-1 php -d xdebug.mode=off $(which composer) install - 根治办法：收紧版本约束、删
vendor/和composer.lock后重装
全局镜像配置为何经常静默失效？
不是镜像不行，是命令写错后 Composer 会悄悄 fallback 到官方源，且不报错。
- 三要素缺一不可：
repo.packagist（单数，不能多s）、中间的composer（type 值，不可省）、URL 必须是https://mirrors.aliyun.com/composer/（末尾/不可少） - 验证必须用：
composer config -g repo.packagist，输出为空、null或仍是packagist.org就说明没生效 - CI/CD 或宝塔环境要注意用户身份：
sudo -u www composer config -g ...才能写进对应用户的~/.composer/config.json
真正影响打包速度的，是 dist.url 是否被刷新、PHP 内存是否够、xdebug 是否关——这些细节比选哪个镜像重要得多。
