Composer自身安装和self-update不走镜像，因其直接从硬编码的https://getcomposer.org/download/下载；镜像仅影响依赖安装（如create-project、global require）中的元数据与ZIP包拉取。
Composer中文镜像不影响 Composer 自身的安装过程——因为 composer install 或 composer update 安装的是项目依赖，而 Composer 本身是通过独立安装脚本（php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"）或包管理器（如 apt、brew）获取的，不走 Packagist 元数据协议。
为什么 composer self-update 不走镜像
执行 composer self-update 时，Composer 直接从 https://getcomposer.org/download/ 下载二进制文件，完全绕过 repo.packagist 配置。该 URL 是硬编码在源码中的，镜像设置对其无任何影响。
- 镜像源只参与
packages.json、p2/xxx/xxx.json等元数据拉取，以及 ZIP 包下载（--prefer-dist模式） -
self-update的行为与repositories配置无关，删掉composer.json里的repositories也不影响它 - 如果你看到
self-update卡住，问题出在 DNS、TLS 或 CDN 节点（如 getcomposer.org 在国内偶尔不稳定），不是镜像没配好
但 composer create-project 会受镜像影响
运行 composer create-project laravel/laravel 这类命令时，Composer 会先解析 laravel/laravel 的依赖树，这一步需要访问镜像源的 p2/ 接口获取元数据——此时镜像是否生效，直接决定命令能否成功、速度如何。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 如果镜像配置错误（比如
repo.packagist拼成repos.packagist），create-project会 fallback 到packagist.org，大概率超时或 403 - 若项目模板自带
"repositories": {}，全局镜像被屏蔽，create-project同样走官方源 - 验证方式：加
-vvv参数，看日志里是否出现GET https://mirrors.aliyun.com/composer/p2/laravel/laravel.json
composer global require 的依赖安装才真正用镜像
当你运行 composer global require laravel/installer，这个操作本质是往 ~/.composer/vendor/ 安装包，属于标准的依赖解析流程，全程走 repo.packagist 配置。
- 这里镜像必须生效，否则
global require会卡在元数据加载阶段 - 注意全局配置的用户一致性：你在终端以
root配了镜像，但sudo composer global require可能写到/root/.composer/config.json，而实际运行时 PHP CLI 用的是www用户，就读不到 - 推荐做法：进
~/.composer目录后，直接运行composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g），这样写入的是当前用户的项目级配置，更可靠
最容易被忽略的一点：镜像只管“依赖怎么装”，不管“Composer 怎么来”。很多人反复重装 Composer，却没意识到慢的从来不是它自己——而是第一次 create-project 或 global require 时，元数据请求被墙或超时。配镜像不是为了装 Composer，是为了让它能顺利装别人。
