最可靠方式是用 composer self-update 指定版本，如 composer self-update 2.5.8 或 composer self-update 2.6.0-rc1；注意权限、路径及 shell 缓存问题，避免误用 installer 脚本或 platform 配置。
安装特定 Composer 版本用 composer self-update
Composer 官方不提供按语义化版本号直接安装的命令，但 self-update 支持指定具体版本（包括预发布版）。这是最可靠、最常用的方式。
常见错误是误以为 curl -sS https://getcomposer.org/installer | php 能装指定版本——它只装最新稳定版，且会覆盖现有安装。
- 装 2.5.8：
composer self-update 2.5.8 - 装带 rc 的预发布版（如 2.6.0-RC1）：
composer self-update 2.6.0-RC1 - 降级前建议先备份当前二进制：
cp $(which composer) composer-backup - 执行后检查是否生效：
composer --version，注意输出中包含完整版本号和 commit hash
composer self-update 不生效？可能是权限或路径问题
执行成功但 composer --version 没变，大概率是 shell 缓存了旧的可执行文件路径，或当前用户无权写入 Composer 安装目录。
- 运行
which composer看实际路径，常见位置有/usr/local/bin/composer或~/.local/bin/composer - 如果提示
Permission denied，不要加sudo——改用composer self-update --snapshot（装最新快照）或手动下载：php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"+php composer-setup.php --install-dir=/your/path --filename=composer - 更新后仍显示旧版本？运行
hash -d composer（bash/zsh）清除命令哈希缓存
项目内锁定 Composer 版本：靠 composer.json 的 platform 配置没用
platform 只影响 PHP 扩展和 PHP 版本模拟，**完全不控制 Composer 自身版本**。想确保 CI 或队友用同一版 Composer，必须外部约束。
- CI 场景（GitHub Actions）：用
composer self-update 2.5.8显式指定，别依赖系统预装版 - Docker 构建：在
Dockerfile中写死RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer && composer self-update 2.5.8 - 团队协作：把期望版本写进
README.md，并配合 pre-commit hook 检查composer --version输出
Windows 下用 Scoop / Chocolatey 安装特定版本要格外小心
Scoop 和 Chocolatey 的 Composer 包通常只维护 latest，不提供历史版本索引。强行指定版本容易失败或装错包名。
- Scoop 默认只支持
scoop install composer，若需旧版，得手动 clone bucket 并 checkout 历史 commit，再scoop install本地 manifest - Chocolatey 的
choco install composer --version=2.5.8理论上可行，但实际常因包维护滞后而报Package not found - 更稳的做法：Windows 用户直接下载 phar 文件（如
https://getcomposer.org/download/2.5.8/composer.phar），重命名为composer，加入 PATH
Composer 版本差异会影响插件兼容性、依赖解析策略（比如 2.2+ 对 conflict 的处理更严格），还有部分私有仓库认证方式变更。别只看 --version 输出，真要用旧版，务必在真实项目里跑一遍 composer install 看锁文件和依赖树是否一致。
