应使用 composer self-update 升级，它自动校验签名、原子替换并失败回退；无需重装或删旧文件，禁用 --stable 参数（已失效），降级需显式指定版本，升级后需验证路径与缓存。
直接装最新稳定版：用官方推荐的一行命令
Composer 官方明确要求，composer self-update 是唯一推荐的升级方式——它自动校验签名、原子替换文件、失败回退保留旧版，比手动下载更安全可靠。你不需要重装、不用删 composer.phar、也不该用包管理器（如 Homebrew）混管。
- 运行
composer self-update即可升到最新稳定版（当前是 v2.7.7，截至 2026 年 2 月） - 如果提示
Permission denied，说明你没权限写入当前composer所在路径（比如/usr/local/bin/composer），此时应加sudo：sudo composer self-update - 若已用
$HOME/bin方式安装（无 root 权限场景），则无需sudo，直接运行即可
想锁定 stable 版本？别用 --stable 参数
composer self-update --stable 这个参数早已失效——自 Composer 2.0 起，self-update 默认只拉取稳定版，--stable 不再有实际作用，文档里也已移除。所谓“stable”，指的是不带 -alpha、-beta、-rc、-dev 后缀的正式发布版本，而 self-update 本来就不碰预发布通道。
- 误加
--stable不报错，但也不会改变行为 - 真要降级或切版本，必须显式指定，比如：
composer self-update 2.5.8 - 注意：Composer 1.x 已于 2022 年终止维护，指定
1.10.22等旧版可能因签名过期或 CDN 下线而失败
为什么 self-update 比重装更安全？
手动下载 composer.phar 再挪动覆盖，容易漏掉校验、覆盖失败、权限错乱，甚至意外破坏软链接。而 self-update 在内部做了三件事：先下载新 PHAR 到临时路径、用 SHA384 校验签名、原子重命名替换——整个过程失败即中止，旧版始终可用。
- 常见错误现象：
curl: (7) Failed to connect或Signature mismatch，多因网络代理或镜像源干扰，可临时设环境变量：export HTTP_PROXY=http://127.0.0.1:8080 - 升级后运行
composer --version和composer diagnose双重验证，后者会检查 PHP 扩展是否仍兼容（比如 openssl 是否启用） - 如果你用的是 Docker 或 CI 环境，建议固定版本号更新（如
composer self-update 2.7.7），避免非预期升级引发构建波动
装完就以为稳了？别忽略 PATH 和 shell 缓存
升级成功不代表终端立刻识别新版本——尤其当你改过 PATH 或用了 Zsh/Bash 混合环境时，shell 可能还缓存着旧的 composer 路径。
- 执行
which composer看实际调用路径，再对比ls -l $(which composer)确认是否为最新时间戳 - 如果输出是
/usr/local/bin/composer但composer --version显示旧版，大概率是 shell 命令哈希未刷新，运行hash -d composer或直接重启终端 - Mac 上用 Zsh 的用户，常因忘记
source ~/.zshrc导致$HOME/bin未生效；Linux 用户若改过/etc/environment，需登出重登录才刷新全局 PATH
真正麻烦的从来不是命令本身，而是权限路径和 shell 缓存这两层隐形依赖。每次 self-update 后花 10 秒跑一遍 which + composer --version + hash -l | grep composer，比事后排查依赖冲突省力得多。
