Composer self-update 失败主因是权限、签名验证或旧版残留，直接删除二进制文件重装更可靠；新版默认启用GPG签名验证，需确保系统时间准确、密钥可信，Windows需检查composer.bat路径及权限，Linux/macOS应避免sudo更新而改用用户级安装。
Composer self-update 失败，大概率不是网络问题，而是权限、签名验证或旧版残留导致的——直接删掉二进制文件重装反而更快更稳。
为什么 composer self-update 总卡在 signature verification failed
新版 Composer（2.5+）默认启用签名验证，会检查 Phar 包的 GPG 签名。如果本地没有可信密钥、或系统时间偏差 >5 分钟、或之前用 --snapshot 安装过开发版，就容易触发 signature verification failed 错误。
- 运行
date确认系统时间是否准确（尤其 WSL 或虚拟机） - 执行
composer config -g --unset github-oauth.github.com清理可能干扰的 OAuth 配置 - 临时关闭签名验证仅用于诊断：
composer self-update --no-sig（不推荐长期使用）
Windows 上提示 “Access is denied” 或找不到 composer.phar
Windows 下 Composer 通常以 composer.bat + composer.phar 形式存在，而 self-update 默认只更新 Phar 文件。若 composer.bat 指向了旧路径，或当前用户无权写入安装目录（如 C:\ProgramData\ComposerSetup\bin\），就会失败。
- 用
where composer查看实际调用路径 - 用
composer --version和composer --help确认是否真为 Phar 版本（非 Windows Installer 封装版） - 若确认是官方 Phar 安装，直接删除
composer.phar和同级composer.bat，再从 getcomposer.org/installer 下载最新composer.phar，重命名并放回原位置
Linux/macOS 权限错误：Permission denied on /usr/local/bin/composer
多数人把 Composer 装在 /usr/local/bin/composer，但该路径属 root，普通用户无法覆盖。此时 self-update 会报错，且不会自动降级为用户目录安装。
- 别硬加
sudo composer self-update—— 这会让后续所有composer命令都需 sudo，极不安全 - 改用用户级安装：
php -r "copy('https://www.php.cn/link/e910517884e11c8a741c3b1da823f47e', 'composer-setup.php');"→php composer-setup.php --install-dir=$HOME/bin --filename=composer - 确保
$HOME/bin在$PATH中靠前（检查echo $PATH），否则终端仍会优先找到系统级旧版
真正麻烦的不是更新失败本身，而是很多人反复试 --rollback、--stable、清缓存，却没意识到：Composer 的自我更新机制在旧版（2.2 但非 LTS）上本身就不可靠。最省事的解法，是接受它“不适合热更新”的事实，用下载替换代替修复。
