composer self-update 默认只升级到当前主版本的最新稳定补丁版（如2.5.8→2.5.10），不跨主版本、不升预发布版，且为全局操作；强制升级需显式指定版本或通道（如--3）。
Composer 的 self-update 命令能升级自身，但默认只升级到当前稳定分支的最新补丁版本（如从 2.5.8 升到 2.5.10），不会跨主版本（如不自动从 v2 升到 v3）。
composer self-update 默认行为是什么
执行 composer self-update 时，Composer 会检查官方发布的最新稳定版（按当前主版本锁定），下载 phar 文件并替换本地二进制。它不改变主版本号，也不升级到预发布版（如 2.6.0-RC1）。
- 若你装的是
2.2.20，运行后可能升到2.2.24，但不会变成2.3.0 - 若已是最新的稳定小版本，命令会提示
You are already using the latest available version - 该命令不依赖
composer.json或项目上下文，是全局操作
如何强制升级到指定主版本（如 v2 → v3）
v3 是一个不兼容 v2 的主版本，self-update 不会自动跨过去。必须显式指定版本或通道：
- 升级到最新 v3：
composer self-update --2（注意是--2表示 v2 分支，--3才是 v3） - 升级到特定 v3 版本：
composer self-update 3.0.2 - 回退到 v2 最新版：
composer self-update --2 - 查看当前通道和可用版本：
composer self-update --list
⚠️ 注意：--3 仅在 Composer 2.5+ 中支持；旧版需先用 self-update 升到 2.5+ 再执行。
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
升级失败常见原因和绕过方法
权限、网络或签名验证问题常导致 self-update 失败，错误信息类似 file_put_contents(…): failed to open stream: Permission denied 或 Signature mismatch。
- 权限不足：Linux/macOS 下用
sudo composer self-update（不推荐长期使用）；更安全的做法是重装到用户目录：php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" && php composer-setup.php --filename=composer --install-dir=$HOME/bin - 国内网络超时：设置镜像源再更新：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意该镜像已停用，建议改用https://mirrors.aliyun.com/composer/），然后重试 - 签名验证失败：临时跳过（仅调试用）：
composer self-update --no-sig-check，但生产环境禁用
验证升级是否生效及版本兼容性提醒
升级后务必运行 composer --version 确认输出版本号，并检查项目是否仍能正常 install 或 update。
- v3 移除了
composer.lock中的content-hash字段，改用更严格的锁文件校验逻辑，老项目首次用 v3 install 可能报错The lock file does not contain require-dev information，此时需删掉composer.lock重新生成 - v2 和 v3 的
autoload生成规则有细微差异，若用到了自定义 PSR-4 映射或 classmap，建议升级后跑一次composer dump-autoload -o - CI 环境中应固定 Composer 版本（如 GitHub Actions 用
composer/setup-php@v2指定composer-version: '3.0.2'），避免因自动升级导致构建不稳定
主版本升级不是“点一下就完事”，尤其 v2 → v3 涉及锁文件结构、插件 API 和依赖解析策略变化，得实际跑一遍 composer install 和单元测试才能确认是否真就绪。
