sudo composer config -g没生效是因为它以root身份执行，将配置写入/root/.composer/config.json，而普通用户读取的是自己的~/.composer/config.json；正确做法是去掉sudo或用sudo -u 用户名切换目标用户执行，并验证composer config -g repo.packagist输出是否为完整json。
直接改 repo.packagist 就行，但必须用目标用户身份执行，否则配置写进 /root/.composer/config.json，普通用户完全读不到。
为什么 sudo composer config -g 没生效
很多人在脚本里写 sudo composer config -g repo.packagist https://mirrors.aliyun.com/composer/，结果 composer install 还是走国外源。这是因为 -g 写的是当前用户的 ~/.composer/config.json，而 sudo 切换到了 root 上下文，实际改的是 /root/.composer/config.json。
- 确认当前执行用户：运行
whoami，比如是deploy - 正确做法：去掉
sudo，直接运行composer config -g repo.packagist https://mirrors.aliyun.com/composer/ - 若必须用 root 调度：改用
sudo -u deploy composer config -g repo.packagist https://mirrors.aliyun.com/composer/ - 验证是否写对：执行
composer config -g repo.packagist，输出应为镜像地址；同时检查~/.composer/config.json中"repositories"字段是否已更新
别用已停服的 packagist.phpcomposer.com
截至 2026 年，https://packagist.phpcomposer.com 已彻底下线。脚本里硬编码这个地址，会导致所有 composer install 报 Could not fetch https://packagist.phpcomposer.com/packages.json 或无限超时。
- 目前唯一稳定可用的官方推荐镜像只有两个：
https://mirrors.aliyun.com/composer/（首选）、https://mirrors.cloud.tencent.com/composer/（备选） - 禁用非官方源，例如
https://packagist.laravel-china.org—— 多年未同步，包索引严重滞后，composer require可能拉到过期或不存在的版本 - 如果项目中已有旧配置，先清理再重设：
composer config -g --unset repo.packagist，再重新config -g repo.packagist
权限错导致 cache 写入失败
脚本跑完 composer config -g 后，composer update 卡在 “Loading repository data…” 或报 Failed to write cache file，大概率是 ~/.composer 目录归属或权限不对。
- 常见诱因：之前手动执行过
sudo composer，导致~/.composer归属为root:root，当前用户无写权限 - 修复命令：
chown -R $USER:$USER ~/.composer（注意不是sudo chown，除非你确定要改 root 用户的目录） - 补一手保险：确保
~/.composer目录存在且可写，可加判断逻辑：[ ! -d ~/.composer ] && mkdir -p ~/.composer && chmod 755 ~/.composer - 如果 PHP 是多版本共存（如通过
/usr/local/php81/bin/php调用），记得所有操作都用同一套 PHP CLI 环境，避免扩展加载不一致
最常被忽略的一点：配置镜像源只是第一步，~/.composer 目录权限、PHP CLI 扩展完整性（openssl、mbstring、zip）、以及是否真的用目标用户执行——这三者任一出问题，都会让镜像配置“看起来生效了”，实则请求仍发往 packagist.org。
