Windows上改镜像源仍走packagist.org，主因是终端环境不一致导致配置写入与读取路径错配：CMD/PowerShell读%APPDATA%\Composer\config.json，Git Bash读WSL的~/.composer/config.json，且未重启终端致旧进程缓存未更新。
为什么改了镜像源，Windows 上还是走 packagist.org？
不是镜像地址本身有问题，而是 composer config -g 写入的位置和读取时的环境不一致。Windows 下不同终端（CMD、PowerShell、Git Bash）对 $HOME 或 %APPDATA% 的解析逻辑不同，导致配置可能写进 A 文件却从 B 文件读取。
- CMD 和 PowerShell 默认用
%APPDATA%\Composer\config.json，但 PowerShell 若未显式设编码，写入含非 ASCII 字符（比如中文注释）会损坏 JSON 格式 - Git Bash 用
~/.composer/config.json，而这个~指向的是 WSL 的 home 目录，和 Windows 原生环境完全隔离 - 执行
composer config -g repo.packagist后必须重启终端，否则旧进程仍缓存旧配置 - 验证是否生效别只看
composer config -gl，要加-vvv跑一次composer install，观察日志里实际请求的域名是不是mirrors.aliyun.com
Linux/macOS 和 Windows 的镜像配置命令写法有区别吗？
命令本身没区别，但包裹 URL 的引号、末尾斜杠、执行权限这三点必须统一处理，否则跨平台行为就会分裂。
- URL 必须用双引号包裹：
composer config -g repo.packagist "https://mirrors.aliyun.com/composer/"—— 单引号在 PowerShell 里会失效，漏引号则空格或特殊字符直接报错 - URL 末尾必须带
/，否则 PHP 的parse_url()在某些版本下返回 false，触发Invalid argument错误，这跟系统无关，但在 Windows 上更常被误判为编码问题 - Linux/macOS 推荐用当前用户执行，不要加
sudo；Windows CMD 需管理员权限才能写入%APPDATA%，PowerShell 则建议用powershell -Command "..."显式控制编码
项目级 repositories 配置为什么会悄悄覆盖全局镜像？
这是 Composer 的配置优先级规则：项目级 composer.json 中的 repositories 字段永远高于全局 repo.packagist，且不提示、不警告，静默覆盖。
- 检查方式很简单：
composer show --tree | head -10看依赖来源，或直接打开项目根目录下的composer.json，搜"repositories" - 常见坑是旧项目遗留了
"packagist.org": false或指向已停服的镜像（如https://packagist.laravel-china.org），结果全局配了阿里云也无效 - 修复不是删掉整个
repositories，而是确保它里面只有一条合法 packagist 声明，且url和全局一致，否则反而引入冲突 -
composer clear-cache必须在修改配置后立刻执行，否则旧元数据缓存会继续误导安装流程
阿里云/腾讯云/华为云镜像在不同系统上表现真不一样？
镜像服务本身不区分操作系统，差异来自 CDN 节点调度、同步延迟、以及你本地出口 IP 所属网络类型（电信/联通/教育网），和 Composer 运行在哪套系统上无关。
- 阿里云对华南、华东用户延迟最低，但教育网出口偶尔走不通；清华镜像在北方高校内极快，南方用户 DNS 解析可能慢 200ms+
- 华为云镜像不保留已删包，如果你的
composer.lock锁定了一个已被作者下架的版本，换镜像也救不回来 - 腾讯云 CDN 覆盖广，但南方部分地区偶发
502 Bad Gateway，此时换用https://mirrors.ustc.edu.cn/composer/往往能绕过 - 别信“某镜像专为 Windows 优化”这种说法——所有镜像都是 HTTP(S) 服务，唯一影响体验的是你机器到那个 CDN 节点的链路质量
composer.json 又是第四个。跨平台一致性，靠的不是“适配”，是主动收敛入口和验证手段。 
