不能用composer self-update降级到1.x，因2.x更新机制只对接v2发布通道，强行执行会报“Could not find version”或静默失败；必须卸载后重装1.10.22并清理composer.lock、allow-plugins及auth.json等不兼容配置。
不能用 composer self-update 降级到 1.x —— 这条命令在 Composer 2.x 中根本就拒绝识别 v1 版本号，强行运行只会报错或静默失败。
为什么 composer self-update 1.10.22 一定失败
Composer 2.x 的更新机制只对接 v2.x 的发布通道，请求时会固定拼接 v2 的 API 路径。即使你输的是 1.10.22，底层仍向 v2 接口发请求，服务器直接返回 “Could not find version” 或跳过处理。这不是网络问题，是设计上切断了跨大版本通道。
常见错误现象包括：
Could not find version 1.10.22- 执行后
composer --version输出不变 - 提示
Up to date，但实际仍是 2.x
别试 composer self-update --1：该参数早在 2.0 发布时就被移除，现在运行会报 Unknown option: --1。
必须卸载再装 1.10.22 的实操步骤
v1.x 最后稳定版是 1.10.22（2022 年 10 月发布），它支持 PHP 5.3–7.4，且能兼容绝大多数遗留插件（如 fxp/composer-asset-plugin 替代方案缺失的场景）。关键动作不是“降级”，而是干净替换。
操作顺序如下：
- 运行
which composer确认路径（常见为/usr/local/bin/composer） - 用
sudo rm /usr/local/bin/composer彻底删除当前二进制 - 下载并校验：
curl -sS https://getcomposer.org/download/1.10.22/composer.phar -o /tmp/composer-v1.phar，再用官网公布的 SHA384 值核对（跳过=风险） - 移动并赋权：
sudo mv /tmp/composer-v1.phar /usr/local/bin/composer && sudo chmod +x /usr/local/bin/composer - 验证：
composer --version应输出Composer version 1.10.22
降级后必须同步清理的三处残留
1.x 和 2.x 的 lock 文件格式、插件加载机制、依赖解析策略互不兼容。不清理会引发静默失败或行为偏移。
- 删掉项目根目录下的
composer.lock：1.x 无法读取 2.x 生成的 lock 文件，会直接报Invalid argument - 删掉
composer.json中的allow-plugins字段：1.x 不识别该配置，保留会导致Plugin installation failed - 检查
auth.json认证方式：1.x 不支持 2.x 引入的 token-based 认证格式，需回退为http-basic形式
常见卡点：执行 composer install 仍卡在「Loading composer repositories」
这是最典型的症状，本质是 1.x 在尝试用 HTTPS 请求旧式仓库元数据时因证书或重定向失败而阻塞。不是配置写错了，是默认行为差异。
临时解法（仅调试用）：
- 加
-vvv看真实请求 URL：composer install -vvv - 若发现请求发向
packagist.org/api/且超时，手动在composer.json中显式指定镜像："packagist.org": {"url": "https://packagist.phpcomposer.com"}（注意：该镜像已停用，应换国内可用镜像如https://mirrors.aliyun.com/composer/） - 1.x 对镜像 URL 格式更宽松，但要求末尾带斜杠；2.x 则更严格
真正要盯住的，是 composer.json 里 repositories 的结构是否含 2.x 特有的字段（如 type: "composer" 配合 package 数组），这些在 1.x 下会被忽略或报错。
