composer config -g repo.packagist 命令没生效是因为键名必须为单数repo.packagist、第二个参数必须显式写composer、URL必须以/结尾，任一缺失均静默回退官方源且不报错。
composer config -g repo.packagist 命令为什么没生效
90% 的“配了还是慢”问题，根本不是网络或镜像本身的问题，而是这条命令写错了关键三处，且 Composer 2.x 会静默 fallback 到官方源，不报错也不提示。
-
repo.packagist是固定键名——写成repos.packagist（多一个 s）或packagist.org都无效 -
composer是必须显式的type值，不能省略；漏掉它，Composer 就当没这行配置 - URL 必须是 HTTPS 且末尾带斜杠：
https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致请求路径拼成/composerpackages.json，404）
验证是否真写进去了：运行 composer config -g repo.packagist。输出应为完整 JSON 对象（如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}），空、null 或只返回 URL 字符串，都说明没写对。
宝塔/CI 环境下全局配置为何总失效
全局配置写在 ~/.composer/config.json，但「谁在跑命令」决定读哪个文件。宝塔后台的「一键部署」默认以 www 用户执行，CI 流水线用的是 runner 用户，它们根本看不到你本地 root 或当前登录用户的配置。
- 在宝塔里执行
composer config -g，实际写入的是/root/.composer/config.json，而部署脚本读的是/home/www/.composer/config.json或/www/wwwroot/xxx/.composer/config.json - CI 脚本里用
sudo composer config -g，结果写进了root配置，但容器里跑的是非 root 用户，照样不生效 - Windows 用户配置文件路径在
C:\Users\用户名\AppData\Roaming\Composer\config.json，别手写，用命令更安全
结论：在多用户、容器化或托管环境中，-g 全局配置基本不可靠。
项目级配置如何安全追加而不破坏私有源
进项目根目录，直接运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加 -g）。这条命令会自动识别 composer.json 中已有的 repositories 结构，并安全合并。
- 如果原先是
"repositories": {}（空对象），命令会把它转成标准数组格式，并插入 packagist 条目 - 如果原先是
"repositories": []（空数组），命令会向数组末尾追加新项，不会覆盖已有私有仓库 - 千万别手动写
"packagist": false——这会彻底关掉基础包校验，导致php、ext-json等核心依赖无法安装
改完后必须删掉 vendor/ 和 composer.lock，再执行 composer install。旧 lock 文件记录的是官方源的哈希值，和镜像元数据不匹配，强行保留会报 hash does not match。
换源后仍卡在 “Resolving dependencies” 怎么办
镜像只加速元数据拉取和 ZIP 包下载，不解决依赖解析慢的问题。如果你发现 composer update 卡在 Resolving dependencies 几十秒以上，基本和镜像无关，而是本地约束太松或配置不合理：
-
"php": "^7.4 || ^8.0"这类宽泛版本约束会让 Composer 尝试大量组合，拖慢解析 -
require-dev里塞了太多未锁定的工具包（如"phpunit/phpunit": "dev-main"） - 大量使用
dev-分支而非稳定版 tag，触发频繁远程元数据查询
这类问题只能靠收紧版本约束、移除冗余 dev 依赖、或升级到 Composer 2.9.6（它优化了依赖解析算法，对大型框架项目提升明显）来缓解——换镜像没用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
