Composer全局镜像唯一生效命令是composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，必须严格包含-g、单数键名repo.packagist、composer类型值及末尾带/的HTTPS URL，缺一静默失效。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能生效，但漏掉任意一个关键要素——比如少个 /、写错键名、缺 composer 类型值——都会静默失败，且不报错。
为什么 composer config -g repos.packagist 不生效
Composer 内部硬编码只识别 repo.packagist（单数 repo），不是复数 repos。写成 repos.packagist 后，配置会悄悄写进一个无效字段，composer config -g repo.packagist 查出来是空或 null，install/update 仍走官方源。
验证方式：运行 composer config -g repo.packagist，正确输出应为类似：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}如果返回空、null 或报错，说明没写对，不是网络问题。
Windows 用户改完必须重启终端
Windows 下改完全局配置后，当前终端进程不会自动读取新配置。不重启，composer 仍用旧的环境变量和配置缓存。
通过 handsfree-windows CLI控制 Windows 本机应用 (UIA) 和浏览器 (Playwright) 的引导技能，用于自动化或测试桌面应用。
- 关闭所有已打开的 CMD / PowerShell / Windows Terminal 窗口
- 重新打开一个全新终端再执行
composer install或composer diagnose -
composer diagnose输出中看Repo packagist.org:后面是否为你设的镜像地址
项目级配置比全局更可靠
全局看着省事，但协作和 CI 场景下容易出问题：
- 某些项目在
composer.json里写了"repositories": {"packagist.org": false}，会直接屏蔽全局设置 - CI 流水线里用户身份和全局配置用户不一致（比如宝塔后台以
www用户运行，但-g写的是root的配置），镜像就不生效 - 团队协作时，全局配置无法被 Git 跟踪，新人拉代码后行为不一致
推荐做法：进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会自动在 composer.json 顶层写入 "repositories" 字段，key 固定为 "packagist"，不会覆盖已有私有源——只要原来 repositories 是对象（不是数组），命令就会安全合并。
验证镜像是否真在用
别信“命令跑完了”，要亲眼看到请求发到了镜像域名上才算数：
- 先清缓存：
composer clear-cache - 新建空目录，执行
composer init -n && composer require monolog/monolog --no-install，观察日志里Downloading行是不是mirrors.aliyun.com这类域名 - 或者更直接：
composer show laravel/framework 11.* -vvv 2>&1 | grep "Downloading"，过滤出实际请求地址 - 如果看到
packagist.org或报Could not fetch https://mirrors.xxx//p2/，可能是 DNS 不通或镜像临时不可用，换一个试试（如中科大：https://mirrors.ustc.edu.cn/composer/）
URL 末尾那个 / 容易被忽略，少它会导致路径拼成 /composerpackages.json 直接 404；composer 这个 type 值也常被当成注释省略，但它不是可选参数——缺了就 fallback 到默认源。
