用 composer require vendor/package:1.2.3 可精确安装指定版本，不升级、不漂移；需注意大小写敏感、tag需加引号或=前缀、commit用dev-branch#hash格式，并验证composer.lock与实际commit hash。
直接用 composer require vendor/package:1.2.3 最可靠
想装哪个版本就是哪个版本，不升级、不漂移，核心就一条：在包名后加冒号和**精确版本号**。比如装 Monolog 的 2.1.0，就写 composer require monolog/monolog:2.1.0。
- 它会自动写进
composer.json的require字段，且不带^或~，锁死为 exact 版本 - 如果包已存在，
require默认会尝试升级；加--no-update可先改配置再手动composer update - 别写
^2.1.0或~2.1——它们允许小版本或补丁更新，不是“指定版本”的本意 - 包名大小写敏感：
monolog/monolog对，Monolog/Monolog会报Could not find package
composer install 不接受版本参数，别在这儿试
composer install 的作用是按 composer.lock 还原依赖，它根本不看命令行传的版本号，也不读 require 命令里的冒号写法。你输 composer install monolog/monolog:1.2.3，它会直接忽略后面部分，还可能报错 Unknown argument。
- 要换版本，必须先改
composer.json或用require/remove，再跑composer install或composer update vendor/package - 如果只是临时验证某个旧版，建议先
composer remove vendor/package，再require指定版本，避免残留冲突 - 执行后检查
composer.lock里对应包的version和source.reference，确认没被意外解析成 dev 分支
装 Tag 或 commit？语法不对就装错分支
Composer 默认把类似 v2.9.1 的字符串当分支名处理，而不是 tag。不加引号或前缀，很可能拉下 dev-v2.9.1 这种不存在的分支，报 Could not find a matching version。
- 装 tag 推荐写成
"monolog/monolog": "2.9.1"（带引号）或=2.9.1，语义明确，不触发 caret 解析 - 装特定 commit 必须走
dev-main#abc123格式，且该 commit 得在main（或你写的分支名）上存在；composer require vendor/package:dev-main#abc123会失败，得手动改composer.json再update - 私有 Git 库要确保
repositories正确配置类型为vcs，否则 Composer 根本不查那个仓库 - 验证是否真装对了？别只信
composer show输出的dev-main，用git log -n1 vendor/vendor/package看实际 commit hash
为什么 self-update 和包版本是两回事
用户常混淆「Composer 自身版本」和「项目里安装的包版本」。前者用 composer self-update --version 2.5.8 控制，后者完全由 composer.json 或 require 命令决定，两者互不影响。
-
self-update失败常见于国内网络——它直连https://getcomposer.org，不走 packagist 镜像；设COMPOSER_HOME后手动下载 GitHub Releases 的composer.phar替换，反而更稳 - 装旧版包时，如果依赖树里其他包要求更高 PHP 版本或新特性，
composer require可能静默失败或降级别的包；这时用composer why-not vendor/package:1.2.3查阻塞原因比硬试更省时间 - 最隐蔽的坑：某些包的
1.2.3tag 实际对应的是dev-master的某次提交，而它的composer.json里又写了"minimum-stability": "dev"——这会导致整个依赖树稳定性策略松动，连带装进一堆 alpha 包
事情说清了就结束
