答案是命令写错三处即静默失效：键名必须为单数repo.packagist、第二参数必填type值composer、url须https且末尾带/；验证需输出完整json，项目级配置比全局更可靠。
composer config -g repo.packagist 命令为什么总不生效
不是网络问题，是命令写错三个地方就静默失败——不报错、不提示、也不写入配置。
-
repo.packagist必须是单数repo，写成repos.packagist或packagist.org都无效 - 中间的
composer是 type 值，不是可选参数，漏掉就会 fallback 到官方源 - URL 必须是 HTTPS 且末尾带
/，比如https://mirrors.aliyun.com/composer/，少斜杠会拼出/packages.json导致 404
验证是否成功：运行 composer config -g repo.packagist，输出应为 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null 或报 Key not found，说明没写进去，立刻检查拼写和斜杠。
项目级镜像配置比全局更可靠
CI 流水线（GitHub Actions / GitLab Runner）、宝塔面板、Docker 容器里跑的 composer，基本读不到你本地 ~/.composer/config.json —— 因为用户权限不同，配置根本不可见。
- 进项目根目录，执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 它会自动在
composer.json顶层写入"repositories"字段，key 固定为"packagist"，不会覆盖已有私有源 - 如果项目已存在
"repositories"数组，别手动删重写；用命令追加，否则可能丢掉私有包源 - 改完后删掉
vendor/和composer.lock，再跑composer install（不是update）
换源后还卡在 “Resolving dependencies”？和镜像无关
镜像只加速元数据拉取和 ZIP 下载，不解决依赖解析本身慢的问题。这个阶段卡住，90% 是 composer.json 写法或本地环境导致的：
-
"php": "^7.4 || ^8.0"这类宽泛版本约束会让 Composer 尝试遍历大量候选版本 -
require-dev里塞了太多未锁定的 dev 包（比如phpunit/phpunit不带具体版本） - PHP 版本太低（如 PHP 7.2），而某些包的最新版已放弃支持
这类问题换任何镜像都无效，得收紧约束、拆分 dev 包、或用 composer update --with-dependencies 限定范围。
遇到 “Could not fetch” 或 “file could not be downloaded” 怎么办
先别急着重装或换命令，大概率是镜像源临时同步延迟或服务抖动：
- 用
curl -I https://mirrors.aliyun.com/composer/packages.json检查 HTTP 状态码，200 OK 才算正常 - 阿里云偶尔延迟 5–10 分钟，可临时切腾讯云：
composer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/ - 如果用了废弃插件（如
fxp/composer-asset-plugin），它不走镜像配置，得直接升级到yiisoft/yii22.0.14+ 或迁移到 npm/yarn
最易被忽略的是：改了镜像后首次 composer install 报 hash 校验失败，必须删 vendor/ 和 composer.lock 重来，否则旧 lock 文件仍指向海外源地址。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
