直接运行 composer self-update 升级到最新稳定版但不跨主版本，v1 与 v2 在插件兼容性、autoload 性能、依赖解析上不兼容；强制升级用 --2，降级用 --1。
直接运行 composer self-update 即可升级到最新稳定版，但要注意它默认不升级到 v2.x（如果当前是 v1.x）——这是最常被忽略的兼容性断点。
为什么 composer self-update 没有升级到 v2？
Composer v2 是重大版本，v1 和 v2 在插件兼容性、autoload 性能、依赖解析逻辑上不兼容。从 2020 年底起，composer self-update 默认只在同主版本内更新（如 1.10.x → 1.10.y），不会跨主版本跃迁。
- 检查当前版本：
composer --version（输出类似Composer version 1.10.22） - 想强制升级到 v2：用
composer self-update --2 - 想降级回 v1（某些老旧项目必需）：
composer self-update --1 - v2 不再支持 PHP php -v 输出 ≥ 7.2
升级失败常见原因和应对
权限错误、网络超时、国内源未切换都会导致 self-update 中断或卡住。
- 报错
Permission denied: /usr/bin/composer？说明 Composer 安装在系统目录，改用sudo composer self-update（不推荐）；更安全做法是重装为用户级：先curl -sS https://getcomposer.org/installer | php，再mv composer.phar ~/bin/composer并确保~/bin在$PATH中 - 卡在
Downloading...？大概率是 GitHub 下载慢，临时切国内镜像：composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意：该镜像已停用；现推荐用https://packagist.proxy.tencent.com或阿里云源） - 升级后
composer install报Class not found？不是升级失败，而是 v2 默认启用 classmap 优化，需重新生成 autoload：composer dump-autoload -o
CI/CD 环境中如何安全升级
自动化流程里不能依赖交互式升级，且需避免因版本漂移导致构建不一致。
- 固定版本安装比
self-update更可靠，例如 GitHub Actions 中：
curl -sS https://getcomposer.org/installer | php -- --filename=composer --version=2.5.8 mv composer /usr/local/bin/composer
- 不要在
composer.json中写"composer/composer": "^2"—— 这是无效的，Composer 自身不通过依赖管理 - Docker 构建时，建议用官方镜像
composer:2而非自己apt install，避免 PHP 版本错配
真正要留意的不是“怎么升级”，而是“升级后哪些项目会出问题”：PHP 版本、自定义 installer 插件、私有仓库认证方式（v2 对 OAuth token 处理更严格）、以及是否启用了 COMPOSER_HOME 自定义路径——这些地方一动就容易连带失败。
