配镜像不是提速技巧而是 composer install 运行前提，需正确执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（三处关键：键名、type 值、https+斜杠），优先项目级配置，并验证输出及日志确认生效。
配镜像不是“提速技巧”，是让 composer install 能跑起来的前提。国内直连 packagist.org 大概率超时、403 或卡在 Loading composer repositories，根源不在你家宽带，而在 TLS 握手和元数据拉取环节。
composer config -g repo.packagist 命令必须写对三处
90% 的“配了没用”是命令输错，它不报错，但静默失效：
-
repo.packagist是唯一合法键名——写成repos.packagist（多一个 s）或packagist.org都无效 - 中间的
composer是type值，不是可选参数，漏掉就 fallback 回官方源 -
https://mirrors.aliyun.com/composer/必须 HTTPS + 末尾带斜杠，少斜杠会拼出/composerpackages.json导致 404
正确写法：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。验证是否生效：运行 composer config -g repo.packagist，输出必须是完整 JSON 或 URL 字符串；空、null 或仍是 https://packagist.org，说明没写进去。
项目级配置比全局更可靠，尤其适合团队和 CI
全局配置写在 ~/.composer/config.json，但宝塔以 www 用户运行、CI 用 runner 用户、Docker 容器里没你的 home 目录——配置根本读不到。
- 进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g），它会自动往composer.json的repositories字段安全追加，不覆盖已有私有源 - 如果项目已有
"repositories": []（数组），命令会失败；得先手动改成"repositories": {}（对象），再运行 - 千万别手写
"packagist.org": false——这会彻底关掉基础包源，镜像一挂就全崩
换源后仍卡在 Resolving dependencies？和镜像无关
镜像只加速下载和元数据拉取，不解决依赖解析慢的问题。如果你看到日志长时间停在 Resolving dependencies，大概率是：
-
"php": "^7.4 || ^8.0"这类宽泛约束，让 Composer 尝试海量版本组合 -
require-dev里塞了太多未锁定的dev-main包 - 启用了
xdebug或 PHP 内存不足（memory_limit小于 1G）
这类问题换任何镜像都无效，得收紧版本约束、拆分 dev 依赖、关闭调试扩展。
换源后首次 install 报 hash 不匹配？删 vendor 和 lock 重来
composer.lock 记录的是旧源的包哈希值，和新镜像返回的元数据不兼容：
- 直接删掉
vendor/和composer.lock - 再执行
composer install（不是update），让 Composer 从镜像拉取全新元数据并生成新 lock 文件 - 临时验证是否真走镜像：加
-vvv参数，盯日志里有没有GET https://mirrors.aliyun.com/composer/
别信“命令跑完了就完事”，得亲眼看到请求发到了镜像域名才算真正生效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
