Composer self-update失败主因是权限不足、镜像源缓存或PHP版本不兼容；应优先检查/usr/local/bin/composer权限，切换官方源验证更新，或降级至兼容版本如2.4.4。
权限不足：/usr/local/bin/composer: Permission denied
这是最常卡住人的地方——composer self-update 本质是下载新二进制并覆盖旧文件，如果当前用户没权限写入 /usr/local/bin/composer，命令就会直接报错或静默失败。
- 先确认路径：
which composer，再看权限：ls -l $(which composer) - 不推荐硬加
sudo composer self-update：它可能让后续composer install因权限不一致出问题 - 更稳妥的做法是迁移到用户目录：
curl -sS https://getcomposer.org/installer | php -- --install-dir=$HOME/bin --filename=composer，然后确保$HOME/bin在$PATH前置位置 - 如果必须保留系统级安装，且确定安全，再用
sudo composer self-update
明明有新版却提示 “Up to date”
这不是网络慢，而是镜像源在“骗” Composer。阿里云、腾讯云等镜像会代理 https://getcomposer.org/ 的响应，缓存版本检查结果，导致 self-update 根本没连到官方服务器。
- 临时切回官方源：
composer config -g repo.packagist composer https://packagist.org - 再执行：
composer self-update - 升级成功后，立刻换回国内镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI/CD 中务必加
--no-interaction，否则会卡在交互提示上超时
PHP 版本不兼容导致升级后直接崩溃
Composer 2.5+ 要求 PHP ≥ 8.0，如果你还在用 PHP 7.4，self-update 成功后第一次运行 composer --version 就会报 Fatal error: Attribute —— 不是更新失败，而是新版根本跑不起来。
- 先查 PHP 版本：
php -v - 若低于 8.0，别升 Composer 2.5+，改用长期支持分支：
composer self-update 2.4.4（稳定、兼容 PHP 7.4） - 注意：Composer 1.x 已于 2023 年底停止维护，仅作过渡，尽快升级 PHP 环境才是根解
- 升级前务必确认项目依赖是否支持新 PHP 版本，否则可能引发连锁问题
手动更新是最可靠的兜底方案
当 self-update 反复失败、网络异常、GPG 验证卡死或 Docker 容器里只读文件系统时，手动下载替换是最可控的方式。
- 下载最新版：
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" - 校验（推荐）：
php -r "if (hash_file('sha384', 'composer-setup.php') === 'e0012edf3e80b6978849f5eff0d4b4e4c79ff1609dd1ccd8432e510eb8989c97') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"（SHA384 值请以官网为准） - 安装到目标路径：
php composer-setup.php --filename=composer --install-dir=/usr/local/bin - 清理临时文件：
rm composer-setup.php
真正麻烦的从来不是命令本身，而是它暗中依赖的三样东西：PHP 版本、文件权限、镜像源策略——漏掉任何一个，self-update 就会变成一个安静的失败。
