composer self-update 还能用吗？
不能用了。从 Composer 2.5.0 开始，self-update 命令已被官方彻底移除，执行会直接报错：Command "self-update" is not defined。这不是你环境的问题，是 Composer 团队主动废弃了这个命令——他们改用「重装式更新」替代「增量式升级」，所有更新都必须通过官方安装脚本完成。
怎么安全更新到最新版（推荐方式）
必须用官方提供的 PHP 安装脚本重新下载并覆盖，它内置 SHA-384 校验和 GPG 签名验证，手动下载 composer.phar 直接替换属于高危操作。
- 推荐命令（兼容性最好）：
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" && php composer-setup.php --filename=composer --install-dir=/usr/local/bin/ && php -r "unlink('composer-setup.php');" - 快捷写法（需确保
php可用且有写权限）：curl -sS https://getcomposer.org/installer | php -- --filename=composer --install-dir=/usr/local/bin/
-
--install-dir必须和你实际调用composer的路径一致；不确定时先运行which composer查看 - macOS Homebrew 用户常用路径是
/opt/homebrew/bin/，Linux 普通用户多为/usr/local/bin/
为什么不能 chmod +x 然后 ./composer 更新？
composer.phar 是 PHP 归档文件，不是原生可执行二进制。加 +x 权限没意义——它仍依赖系统默认的 php 解释器启动，且完全绕过了签名校验、版本比对和安全回滚逻辑。
- 官方早已下线
self-update后端服务，没有增量补丁包，所谓“更新”只是覆盖文件 - 跳过校验的手动覆盖（如
sudo mv composer.phar /usr/local/bin/composer）可能引入损坏或中间人篡改风险 - 某些 Docker 或 CI 环境中
composer.phar是只读挂载，self-update必然失败，此时只能重装
更新后要立刻检查的三件事
运行完安装脚本不等于更新成功，常见卡点都在路径、缓存和兼容性上。
- 执行
composer --version，确认输出 ≥2.7.0（当前主流稳定版）；若仍是旧版，先查which composer和--install-dir是否匹配 - Shell 会缓存命令路径，执行
hash -d composer（bash/zsh）或重启终端，否则可能还在调旧二进制 - 跨大版本（如从 v2 升到 v3）会影响
composer.lock格式：v3 移除了content-hash字段，首次运行composer install可能报错The lock file does not contain require-dev information，此时需删掉composer.lock重建
真正麻烦的从来不是“怎么升”，而是升完发现项目 require 规则解析变了、插件不兼容、或者 CI 流水线里某个老 PHP 版本跑不动新 Composer —— 更新前最好先在干净环境试一遍 composer install。
