根本不是网络或权限问题，而是三个硬性条件缺一不可：键名必须为单数repo.packagist、type值必须显式写composer、URL必须HTTPS且末尾带/；任一错误即静默回退官方源，验证需输出完整JSON对象。
composer config -g repo.packagist 命令为什么总不生效
根本不是网络或权限问题，而是三个硬性条件缺一不可：repo.packagist 键名必须是单数（写成 repos.packagist 就静默忽略）、composer 类型值必须显式写出、镜像 URL 必须以 / 结尾。漏掉斜杠会拼出 https://mirrors.aliyun.com/composer//p2/... 这类 404 路径；漏掉 composer 参数，配置就变成字符串而非仓库对象，composer config -g repo.packagist 输出可能看似正常，但实际不被识别。
验证是否真写进去了：composer config -g repo.packagist 必须输出完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或只返回字符串，说明没配进去。
项目级配置比全局更可靠，尤其对 Laravel/Symfony 等大型框架
大型框架依赖图复杂，composer.lock 对源地址敏感。全局配置在 CI/CD、Docker、宝塔等场景极易失效：基础镜像可能没初始化 ~/.config/composer/ 目录；执行用户（如 www）读不到 root 的配置；不同项目混用私有源时还会互相覆盖。
推荐直接进项目根目录运行：
立即学习“PHP免费学习笔记（深入）”；
-
composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（不加-g）——自动向composer.json的repositories字段追加条目，不覆盖已有私有源 - 手动确保
repositories中存在"packagist.org": false键（不是"packagist"或"default"），否则 Composer 2.9+ 会忽略该镜像项 - 编辑
composer.json更稳妥：{"repositories": [{"type":"composer","url":"https://mirrors.tuna.tsinghua.edu.cn/composer/"},{"packagist.org": false}]}
换镜像后仍卡在 Resolving dependencies？和镜像无关
镜像只加速 dist 包下载，不解决依赖解析阶段的卡顿。Laravel、Symfony 等大型框架常因以下原因卡住：
-
"minimum-stability": "dev"导致候选版本爆炸，求解器暴力穷举——删掉它能砍掉 80% 解析时间 -
"php": "^7.4 || ^8.0 || ^8.1 || ^8.2"这类宽泛约束，会让 Composer 查几百个包的兼容性元数据 - Xdebug 开着：
php -d xdebug.mode=off $(which composer) install可提速 5–10 倍 -
config.platform.php设为"7.4"却在 PHP 8.5 上运行，触发降级查找逻辑
CI/CD 和 Docker 构建中必须配对缓存路径
只缓存 ~/.composer/cache 是常见误区。Composer 缓存依赖于三者一致性：PHP 版本、composer.lock 内容、镜像源地址。任一变动，缓存即失效。
CI/CD 中务必同时缓存：
-
~/.composer/cache（确保路径落在 SSD 或内存盘，避免挂载 Windows 目录或 NFS） -
vendor/（需保证composer.lock和 PHP 版本严格一致） - Docker 构建时，把
COPY composer.json composer.lock ./放在COPY . .之前，利用分层缓存复用vendor/
临时测试缓存路径是否生效：COMPOSER_CACHE_DIR=/tmp/composer-cache composer install --dry-run，再看 /tmp/composer-cache 下有没有新文件生成。
