composer self-update是官方唯一推荐的升级方式，仅替换composer.phar、自动校验签名并失败回退；若提示“Up to date”却版本陈旧，多因镜像源缓存导致未连官方接口，需先切官方源再执行，升v3须用--3参数且要求≥2.5+版本。
composer self-update 是 Composer 自带的、唯一官方推荐的自身升级机制，它不是重装，而是原子化替换当前的 composer.phar 文件：自动校验 GPG 签名、下载新版、备份旧版、失败时自动回退。你不需要删配置、不碰项目依赖、也不依赖 composer.json。
composer self-update 为什么没反应或总说 “Up to date”
- 这几乎从来不是命令本身失效，而是它被“假性满足”了：
- 你配置了阿里云/腾讯云等镜像源（
composer config -g repo.packagist composer @#@#@#@#@#@#@#@#@#@0），但这些镜像不代理@#@#@#@#@#@#@#@#@#@1的版本接口，导致self-update只能本地比对，误判为最新 -
self-update默认只在当前主版本内滚动（如2.7.6 → 2.7.7），绝不会跨到v3，哪怕 v3 已发布半年 - PHP 版本低于 8.0 时，新版 Composer 启动即报
ParseError: syntax error, unexpected Attribute，但错误可能卡在后续命令里，让你误以为升级“成功了”
- 你配置了阿里云/腾讯云等镜像源（
解决方法：
- 先临时切回官方源：
composer config -g repo.packagist composer @#@#@#@#@#@#@#@#@#@2 - 再执行：
composer self-update - 升级完立刻换回镜像（推荐阿里云）：
composer config -g repo.packagist composer @#@#@#@#@#@#@#@#@#@0
composer self-update --3 报错或不识别参数
-
--3（升 v3）、--2（退回 v2）、--preview等通道参数，仅在 Composer ≥ 2.5+ 中可用 - 如果你当前是
2.2.x或2.4.x，直接运行composer self-update --3会提示未知参数或静默忽略 - 正确做法是分两步：
- 先升到支持通道参数的最低门槛：
composer self-update（让它升到2.5.8或更高） - 再执行：
composer self-update --3
- 先升到支持通道参数的最低门槛：
注意：v3 要求 PHP ≥ 8.0，且首次运行 composer install 会因锁文件格式变更报 The lock file does not contain require-dev information，需手动删掉 composer.lock 重建。
权限拒绝（Permission denied）时别急着加 sudo
- Linux/macOS 下报错
Could not write to /usr/local/bin/composer，说明你当初是用sudo curl装到系统路径的，但当前用户无权覆盖 - Windows 上报
Access is denied，本质是系统锁住了正在运行的composer.phar，加管理员权限也无效
更稳妥的做法是放弃原地升级：
- 下载安装脚本：
php -r "copy('@#@#@#@#@#@#@#@#@#@4', 'composer-setup.php');" - 重装到用户目录：
php composer-setup.php --install-dir=$HOME/.local/bin --filename=composer - 确保
$HOME/.local/bin在$PATH前置（macOS/Linux）或已加入系统环境变量（Windows）
这样后续所有 self-update 都在用户空间完成，不再触发权限问题。
真正容易被忽略的不是“怎么升级”，而是升级后是否真的生效：composer --version 输出末尾的 commit hash 和日期才是关键；which composer 和 where composer 能暴露 PATH 冲突；而 composer diagnose 里的签名验证失败提示，往往指向被污染的网络或错误的系统时间——这些细节一漏，更新就变成一场安静的幻觉。
