不配镜像，composer install 卡在 downloading 或反复超时，是因默认直连 packagist.org 在国内不可达；换镜像非提速技巧，而是安装依赖的前提，需严格遵循 repo.packagist 拼写、类型声明 composer、url 末尾带斜杠等三细节，且注意用户权限与配置作用域差异。
不配镜像，composer install 卡在 Downloading 或反复超时，不是你网速差，是默认直连 packagist.org 在国内根本跑不通——换镜像不是“提速技巧”，而是能装上依赖的前提。
composer config -g repo.packagist 命令为什么总不生效
它不报错，但静默失败，90% 的人栽在这三个细节上：
-
repo.packagist不能写成repos.packagist（多一个s就被忽略） - 第二个参数必须是
composer（这是仓库类型声明，漏掉就 fallback 到官方源） -
URL必须是https://开头且末尾带/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会拼出/composerpackages.json，返回 404）
验证是否真正写入：运行 composer config -g repo.packagist，输出必须是 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 或至少是完整 URL 字符串。如果为空、null 或仍是 https://packagist.org，说明完全没生效。
宝塔、CI、Docker 构建里镜像不生效？用户权限搞错了
你在终端用 root 配了全局镜像，但宝塔后台以 www 用户运行，CI 脚本用 runner 用户，Docker 构建容器里压根没读你的宿主机配置——它们各自读的是自己家目录下的 ~/.composer/config.json。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 宝塔中查实际执行用户：
sudo -u www composer config -g repo.packagist，如果为空，就得用该用户重配：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本别依赖全局配置，改用临时参数更可靠：
composer install --repository-url=https://mirrors.aliyun.com/composer/ - Dockerfile 中不能靠宿主机配置，必须显式写入：
RUN composer config --global repo.packagist composer https://mirrors.aliyun.com/composer/，或直接用--repository-url参数
项目级配置 vs 全局配置：什么时候该用哪个
全局配置省事，但有隐藏风险；项目级更稳妥，尤其团队协作时：
- 全局配置（
composer config -g）改的是~/.config/composer/config.json，所有项目共享。适合个人开发，或团队统一初始化脚本固化 - 项目级配置（去掉
-g，在项目根目录运行）会往composer.json的repositories字段里追加，只影响当前项目。注意：它不会清空已有私有源，但若composer.json已手动定义"repositories": []且不含packagist条目，命令会补上；若已有复杂结构，建议手动编辑确保"packagist.org": false
项目级配置的命令是：composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/
换镜像后还是卡？先看日志里卡在哪一步
加 -vvv 运行：composer install -vvv，盯紧输出关键词：
- 出现大量
GET https://mirrors.aliyun.com/composer/或Downloading xxx.zip→ 镜像已生效，下载环节正在加速 - 长时间停在
Resolving dependencies→ 和镜像无关，是本地 PHP 内存不足、启用了xdebug、composer.json里版本约束太宽（比如"*"）、或config.platform设置不合理 - 反复请求
https://packagist.org/packages.json→ 镜像根本没生效，回退到了官方源
真正容易被忽略的点是：composer.lock 里锁的是 dev 分支或 Git 仓库地址时，Composer 仍会直连 GitHub，绕过镜像源——这类依赖得单独处理，不能只指望换源。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
