composer本身不提供版本切换命令，所谓“切换”本质是控制path中优先命中的可执行文件或显式调用指定phar；self-update无法降级到1.x因2.x更新机制仅对接v2通道，强行执行会报“could not find version”或“unknown option: --1”；可靠方式仅有三种：①用完整路径直接调用不同composer.phar，②重命名+软链管理，③通过homebrew/scoop切换（需对应tap/bucket）。
Composer 本身不提供版本切换命令，所谓“切换”只是控制哪个 composer 可执行文件被调用，或让哪个 PHP 解释器去运行它。直接执行 composer self-update --version 1.10.22 必然失败，这不是操作失误，而是设计限制。
为什么 self-update 无法切到 1.x
Composer 2.x 的更新逻辑只对接 v2 发布通道，输入任何 1.x 版本号都会被忽略或返回 Could not find version。官方早在 2.0 发布时就移除了 --1 这类参数，现在运行会报 Unknown option: --1。
-
self-update只能降级到 2.x 分支内的版本（如2.2.20），且需加引号：composer self-update "2.2.20" - Windows PowerShell 中不加引号会导致点号被解析为命令分隔符
-
self-update --rollback仅回退上一个版本，不可指定，且失败无提示，生产环境慎用 - 网络受限时（如国内），
self-update常卡在 SSL 握手或超时，不是配置问题，是请求路径本身不通
真正有效的切换方式只有三种
核心原则是：不依赖 PATH 顺序，不靠 alias 或软链长期绑定，而是在调用时明确指定目标二进制或解释器。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用完整路径直接调用：
php composer-1.10.22.phar install或php8.2 /usr/local/bin/composer update—— 最安全，不污染环境 - 重命名 + 软链管理：把
composer1和composer2放同一目录，再用ln -sf $(pwd)/composer1 /usr/local/bin/composer切换（macOS/Linux）；Windows 用mklink /D composer composer2 - 通过包管理器切换：Homebrew 需先
brew tap homebrew/php（若已弃用则需找替代 tap），再brew install composer@1，然后brew unlink composer && brew link composer@1；Scoop 同理，但官方仓库通常只维护最新版
切换后必须清理的三处残留
1.x 和 2.x 的 lock 文件格式、插件机制、依赖解析策略互不兼容。不清理会引发静默失败或行为偏移，最典型症状是执行 composer install 卡在 Loading composer repositories。
- 删掉项目根目录下的
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_PHP 环境变量比 alias 更可靠
COMPOSER_PHP 是 Composer 2.2+ 原生支持的方式，只作用于当前命令，不修改系统状态，也不和 config platform.php 冲突。
- 临时生效：
COMPOSER_PHP=/usr/bin/php8.1 composer install - 写入 shell 配置（如
~/.zshrc）：alias composer81='COMPOSER_PHP=/usr/bin/php8.1 composer' - 注意：
config platform.php只影响依赖解析阶段的版本判断，不改变实际运行composer的 PHP 解释器 —— 它骗不了 autoload 生成逻辑，也管不了 scripts 里写的"test": "php tests/run.php"
最容易被忽略的是：切换完版本后，你跑的 composer install 是否真的用了目标 PHP？验证方式只有两个：composer --version 首行输出的 PHP 路径，和 head -n1 $(which composer) 看 shebang 行。两者不一致，所有后续操作都可能白忙。
