composer config -g repo.packagist 总不生效是因为必须同时满足三个硬性条件：键名必须为单数repo.packagist（不能多s）、type值必须显式填composer、url须为https且末尾带/，任一缺失均静默回退官方源。
配错一个字符，Composer 就当没这回事——它不会报错，只会默默切回 packagist.org，让你继续卡在 Installing dependencies。
composer config -g repo.packagist 为什么总不生效
不是镜像慢，是你根本没配进去。这条命令有三个硬性条件，漏掉任意一个，composer 就静默 fallback 到官方源：
-
repo.packagist键名不能多写一个s（repos.packagist是无效字段） -
composer必须作为type值显式写出，不能省略 - URL 必须是 HTTPS 且末尾带
/，比如https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌
验证是否真写进去了，别信“命令跑完了”，直接运行：composer config -g repo.packagist。输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON 对象。空、null、只返回 URL 字符串，都说明失败。
项目级配置比全局更可靠
宝塔用 www 用户跑命令，CI 用 runner 用户，你本地用 root 配的全局设置，它们根本读不到。项目级配置写进 composer.json，拉代码即生效，行为一致：
- 进项目根目录，执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：不加-g） - 如果
composer.json里已有"repositories": {}，命令会安全合并；如果是"repositories": []，命令会向数组追加新项 - 千万别手动写
"packagist": false——这会彻底关掉基础包校验，composer install直接失败
改完后删掉 vendor/ 和 composer.lock，再跑 composer install。旧 lock 文件里的哈希和镜像元数据不匹配，留着只会报 hash does not match。
Docker 和 CI 环境里最容易漏掉的点
很多人在 Dockerfile 里写了 RUN composer config -g repo.packagist，但构建阶段用的是 composer:latest 镜像，运行阶段却切换成 php:8.2-fpm-alpine——配置没同步过去，等于白配：
- 正确做法是在 PHP 运行阶段镜像中重新配置，比如：
RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 或者更稳妥：把配置文件直接写进对应用户的
.composer/config.json路径，例如/var/www/.composer/config.json（对应www-data用户） - 多阶段构建中，若用
COPY --from=composer /app/vendor /var/www/html/vendor，确保构建阶段也用了镜像源，否则vendor里的包还是从国外拉的
换源后还慢？先关掉 xdebug
xdebug 在 Composer 初始化 autoloader 阶段会严重拖慢速度，尤其 ThinkPHP、Laravel 这类框架，可能多耗 3–5 秒：
- 打开
php.ini，把xdebug相关行前面加;注释掉 - 重启 Web 服务或 CLI PHP，再执行
php -m | grep xdebug，无输出即已禁用 - 别指望镜像解决所有慢的问题——依赖解析卡顿、插件冲突（如已废弃的
fxp/composer-asset-plugin）都不走镜像逻辑
镜像只管元数据和 ZIP 包分发，composer install 卡在 Loading composer repositories 才是镜像该管的事；卡在 Resolving dependencies 或 Generating autoload files，就得查 PHP 配置和插件了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
