换镜像后 composer install 仍卡在 packagist.org 是因为 install 仅按 composer.lock 中硬编码的 url 下载，不读取新镜像配置；必须删除 vendor 和 composer.lock 后执行 composer update，才能生成含镜像地址的新 lock 文件。
composer install 仍会照着 composer.lock 里原来的 packagist.org 地址拉包，新镜像根本没机会生效。
为什么换镜像后 composer install 还卡在 packagist.org？
因为 composer install 不解析源配置，只按 composer.lock 中硬编码的 dist.url 和 source.url 下载。哪怕你刚配好阿里云镜像，只要 lock 文件里还是 "url": "https://packages.packagist.org/..."，它就一定去官方源。
- 常见现象：执行
composer install -vvv，日志里全是GET https://packagist.org/...，完全没出现mirrors.aliyun.com - 这不是镜像没配对，是 lock 文件“锁死”了旧路径
-
composer update才会触发新镜像参与解析和下载；install只还原
旧项目必须删 lock + vendor 再 update
想让新镜像真正起作用，得让 Composer 重新生成 composer.lock，把所有包的下载地址换成镜像源地址。
- 先删掉
vendor/和composer.lock（只删vendor不够） - 运行
composer clear-cache，否则缓存里的packages.json元数据还是指向官方源 - 再执行
composer update（不是install），此时才会走新镜像查版本、下包、写新 lock - 如果项目含私有包，确保
composer.json的repositories里已正确定义它们，且认证可用
项目级镜像配置别用 composer config -g 覆盖
在旧项目里直接跑 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 是危险操作——它会把整个 repositories 对象替换成单条镜像，清空你原来配的 Git 私有源、path 包或 Satis 源。
- 正确做法是手动编辑
composer.json的repositories数组 - 首项必须是
{"packagist.org": false}（禁用官方源，防止 fallback） - 第二项才是镜像：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}（末尾/不可省） - 已有私有源（如
"my-vcs": {"type": "vcs", "url": "https://git.example.com/pkg"}）可以放在镜像前后，但不能删
CI/CD 和宝塔环境容易漏掉用户权限
本地配好了全局镜像，上线却还是慢——大概率是因为 CI 或宝塔以 www 用户运行，而你是在 root 下配的 composer config -g，它根本读不到。
- 查实际执行用户：
whoami或看构建日志 UID - 给对应用户单独配：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 更稳妥的做法是：所有环境都走项目级配置（即改
composer.json），不依赖全局设置 - 验证是否生效：
composer update -vvv | grep -i 'mirrors\.aliyun\|tencent\|tuna'，确认请求域名已切换
composer.lock 是唯一可信快照，也是唯一阻碍镜像生效的硬约束。改完配置不删 lock，等于没动。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
