composer自v2.5.0起已彻底移除self-update命令，执行会报“command not defined”，必须通过官方安装脚本重装并校验sha-384与gpg签名，同时确认php≥8.0、路径权限及镜像配置。
为什么composer self-update总显示“Up to date”却还是旧版
你配了阿里云或腾讯云镜像源（比如https://mirrors.aliyun.com/composer/），但self-update会把镜像当“官方”，缓存它的响应，根本没连https://getcomposer.org/校验真实版本。它不是卡在下载，是压根没发请求。
临时切回官方源再更新才是正解：
composer config -g repo.packagist composer https://packagist.orgcomposer self-update- 升级完立刻换回镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
别只信终端输出的“Updated”，一定要跑composer --version看实际数字——Windows 用户尤其要注意 PATH 缓存可能让你看到旧版本。
composer self-update --3报错“Command not defined”怎么办
这不是网络或权限问题，是 Composer 2.5.0+ 已彻底移除self-update命令。你当前版本大概率已是 2.5.x 或更高（比如 2.7.7），但旧命令已不可用。
必须改用官方安装脚本覆盖重装：
- 信任环境可简写：
curl -sS https://getcomposer.org/installer | php -- --filename=composer --install-dir=$HOME/bin - 确保
$HOME/bin在$PATH靠前（检查echo $PATH，必要时加到~/.bashrc或~/.zshrc） - 国内用户若卡在
curl，可先设临时镜像加速：export COMPOSER_HOME=~/.composer，再执行
该脚本内置 SHA-384 和 GPG 双重校验，比旧版self-update更安全，也绕开了镜像源对更新逻辑的干扰。
升级后composer install报错“The lock file does not contain require-dev information”
这是 v3 的典型兼容性表现：v3 重写了composer.lock格式，移除了content-hash字段，并强制要求锁文件包含require-dev信息。老项目用 v2 生成的 lock 文件，v3 会拒绝加载。
解决方式很直接，但容易误操作：
- 删掉现有
composer.lock（不是vendor/） - 运行
composer install重建锁文件（注意：这会重新解析依赖，可能引入小版本变动） - 如果项目有 CI 流水线，务必在
composer install前加--no-interaction，否则构建会卡住
别试图手动修改composer.lock去适配 v3——格式已变，手工补字段无效。
签名验证失败、Permission denied、PHP 版本不匹配这三类静默失败
它们常导致composer self-update或重装脚本中途退出，但终端只显示模糊错误（如file_put_contents(): failed to open stream或空行），没人告诉你真正卡在哪。
逐个拆解：
-
Permission denied：别急着加
sudo。优先重装到用户目录（--install-dir=$HOME/bin），避免系统路径权限纠缠 -
Signature mismatch：可能是代理截断或 OpenSSL 扩展未启用。加
-vvv看日志，或临时用--no-sig-check调试（仅限本地，生产禁用） -
PHP 版本不匹配：Composer 2.5+ 要求 PHP ≥ 8.0。若还在用 PHP 7.4，升级后首次运行就崩在
#[Attribute]语法上。先查php -v，再决定是升级 PHP 还是降级 Composer（composer self-update 2.4.4）
真正容易被忽略的是：重装后，镜像源配置不会自动继承——你之前设的阿里云镜像会丢失，得手动再跑一次composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。
