虚拟主机上全局配置无效，因PHP进程以www等系统用户运行，读不到SSH用户的~/.composer/config.json；必须用项目级repositories数组配置并删除composer.lock和vendor后重装。
为什么虚拟主机上全局配置基本无效
虚拟主机（如宝塔、cPanel、共享主机）通常以固定系统用户（www、apache、nobody）运行 PHP 进程，而你 SSH 登录的账户和 Composer 全局配置（~/.composer/config.json）属于另一个用户。即使你在终端执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，PHP 进程根本读不到那个路径下的配置。
常见现象：composer config -g repo.packagist 在你本地终端输出正确 JSON，但后台执行 composer install 时仍卡在 Loading composer repositories —— 因为实际运行环境压根没加载这条配置。
- 宝塔面板里点“一键部署”或“执行命令”，默认以
www用户执行，需显式切用户：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 某些虚拟主机禁用
proc_open或putenv（常见于安全加固模式），导致config -g直接报错；检查php.ini中是否禁用，重启 PHP 服务才能生效 - Windows 虚拟主机（如 Plesk）中
%APPDATA%\Composer\config.json可能被 IIS 用户隔离，配置后必须重启应用池
项目级配置是唯一可靠方案
把镜像源写进 composer.json 的 repositories 字段，才能确保所有运行环境（包括虚拟主机后台、定时任务、Web 请求触发的 Composer）都强制使用它——因为这个文件随项目一起被读取，不依赖用户上下文。
但要注意格式陷阱：repositories 必须是数组（[]），且第一项必须是禁用官方源的独立对象：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
{
"repositories": [
{"packagist.org": false},
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
]
}
- 如果原
composer.json中"repositories": {}（对象），执行composer config repo.packagist composer https://mirrors.aliyun.com/composer/会把它转成对象形式，但 Composer 2.2+ 已废弃该写法，静默忽略 - 如果已存在私有 VCS 源，别用命令覆盖整个
repositories数组；手动编辑，把阿里云镜像放在首位，并保留{"packagist.org": false}独立项 - 切勿写成
"repositories": {"packagist": {...}}—— 这种对象结构在新版 Composer 中完全不识别
换源后仍卡住？清缓存和锁文件是硬性步骤
虚拟主机常启用 opcache 或 APCu，且 vendor/ 和 composer.lock 往往长期存在。即使你刚改完 composer.json，Composer 仍会优先复用旧 lock 文件里的元数据地址（比如 https://packagist.org/p/...），导致请求依然发往海外。
- 必须删除
vendor/和composer.lock（仅删这两个，composer.json保留） - 执行
composer clear-cache清掉本地元数据缓存（路径通常在/tmp/composer-cache或用户家目录下） - 再运行
composer install --no-cache -vvv，观察日志中Downloading行是否出现mirrors.aliyun.com；若仍见packagist.org，说明repositories格式错误或被其他配置覆盖
临时调试：绕过镜像验证真实瓶颈
如果换源后依然卡在 Resolving dependencies，不是镜像的问题——镜像只加速下载，不参与依赖解析。这时候要快速确认是否真卡在网络环节：
- 加
--no-cache参数强制跳过所有本地缓存：composer install --no-cache -vvv 2>&1 | grep "Downloading" - 用
curl -I https://mirrors.aliyun.com/composer/packages.json验证镜像源本身可访问（注意返回 HTTP 200，且响应头含Content-Type: application/json） - 若
curl正常但 Composer 日志仍无镜像域名，大概率是repositories数组顺序错了，或{"packagist.org": false}缺失，导致 Composer 回退到硬编码的官方源
虚拟主机上最易被忽略的一点：配置写对了，但没删 composer.lock —— 它就像一个“快照”，不删就永远走旧路径。
