直接配composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/可解决90% laravel安装卡顿，但必须严格满足三要素：键名repo.packagist（单数无s）、第二参数composer（type值）、url以https://开头且末尾带/，否则静默失效；验证须执行composer config -g repo.packagist，正确输出为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
直接配 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能解决 90% 的 Laravel 安装卡顿问题，但必须带末尾 /、键名不能多写 s、且得验证输出是否为完整 JSON——否则命令看似执行了，实际完全没生效。
为什么 composer install 卡在 Downloading https://packagist.org/packages.json
这不是 Laravel 慢，是 Composer 在死等元数据。所有依赖解析都从 packages.json 开始，它不下来，后续一步都走不了。国内直连 packagist.org 常因 DNS 解析慢、TLS 握手失败或 CDN 节点远而超时，成功率常低于 40%。
- 现象：命令停在
Downloading https://packagist.org/packages.json或类似provider-laravel~11.0.json请求上 - 本质：不是下载 ZIP 包慢，而是索引拉不下来，整个流程反复重试 3–5 轮
- 验证方式：加
-vvv看日志里真实请求地址，GET https://mirrors.aliyun.com/composer/packages.json才算走镜像
composer config -g repo.packagist 配错的三个静默失效点
这个命令不报错，但写错一个字符就白配。90% 的人根本没生效，还以为自己搞定了。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 键名必须是
repo.packagist（单数，不能写成repos.packagist） - URL 必须以
https://开头，且末尾必须有/，漏掉会触发Could not parse version constraint - 第二参数必须是
composer（type 值），不是git或空字符串 - 验证唯一标准：
composer config -g repo.packagist输出必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
composer create-project 还是慢？补两招才真快
这个命令分两步：先克隆 GitHub 模板（走 GitHub API），再进目录跑 composer install（才走镜像）。第一步卡住，跟镜像无关。
- 第一步卡在
Cloning Laravel repository：大概率是 GitHub API 限流，配composer config -g github-oauth.github.com your_token或改用git clone --depth=1 https://github.com/laravel/laravel.git myapp - 第二步仍慢：确保已全局配镜像，并加参数提速：
--prefer-dist（跳过 git clone）、--no-dev（删 PHPUnit 等开发依赖）、--optimize-autoloader（生成静态映射） - 临时强制走镜像（尤其 CI 场景）：
composer create-project laravel/laravel demo --repository=https://mirrors.aliyun.com/composer/，注意是--repository，不是--repository-url（后者被 Composer 忽略）
缓存没清，镜像再快也白搭
Composer 会优先读本地缓存里的旧 packages.json 和 provider 元数据，哪怕你已经切了镜像，它仍可能反复尝试从 packagist.org 拉取——卡在 DNS 或 TLS 阶段。
- 必须执行：
composer clear-cache（不是composer cache-clear，后者已废弃） - 项目已有
composer.lock且记录的是官方源哈希值？删掉它再跑composer install，否则换源可能失败 - CI/CD 中只缓存
~/.composer/cache不够，还得同时缓存vendor/目录，且要保证composer.lock和 PHP 版本严格一致
最易被忽略的其实是缓存路径和 composer.lock 的耦合关系——镜像配对了、命令加全了，但缓存里还躺着半年前的 packagist.org 元数据，照样卡在第一行。
