最可靠写法是composer require vendor/package:1.2.3
composer require vendor/package:1.2.3 是唯一可靠写法
想精准锁定某个版本，让它不升级、不漂移？秘诀就是 composer require vendor/package:1.2.3。这里面的冒号是关键分隔符，少了它，Composer 会直接报错 Could not parse version constraint，一点商量的余地都没有。
实际操作中，有几个坑特别容易踩：
- 写成
vendor/package@1.2.3或vendor/package=1.2.3—— 这两种写法 Composer 统统不认，结果就是提示Could not find a matching version。 - 包名大小写出错，比如把
monolog/monolog写成Monolog/Monolog。 - 版本号带了
v前缀却没加引号，例如monolog/monolog:v2.9.1。这会让 Composer 误以为你要的是dev-v2.9.1这个分支，一旦找不到，安装自然失败。
命令执行成功后，别忘了去 composer.json 的 require 字段确认一下。如果看到的是 "monolog/monolog": "1.2.3"（前面没有 ^ 或 ~ 符号），那就对了，这才是真正意义上的版本锁死。
装旧版失败时先查清楚是不是版本根本不存在
遇到 Could not find package ... at version ... 这种错误，先别急着怀疑命令。很多时候，问题出在版本本身：可能这个 tag 压根没发布，或者已经被标记为废弃，再或者与当前的 PHP 版本不兼容。
这时候，可以按下面几步快速排查：
- 运行
composer show monolog/monolog --all，在输出的版本列表里找找，看有没有你想要的1.2.3。 - 直接打开 Packagist 上该包的页面，搜索
1.2.3，确认它的状态是stable，并且没有abandoned的提示。 - 如果版本存在但标记为
RC或beta，可以通过参数临时降低稳定性要求：加上--stability=RC，例如composer require monolog/monolog:1.2.3-RC1 --stability=RC。 - 注意，如果是 PHP 版本不匹配，错误信息通常是
Your requirements could not be resolved，这和网络问题无关，盲目清理缓存是没用的。
composer install 不接受任何版本参数
这里有个常见的误解：composer install monolog/monolog:1.2.3 这种写法是无效的。Composer 会静默忽略冒号后面的部分，甚至可能报 Unknown argument。
道理很简单，composer install 的职责非常单一：就是严格按照 composer.lock 文件里记录的信息，还原所有依赖。它根本不会去读取命令行里传递的版本参数。
所以，想更换版本只有两条路：
- 先执行
composer remove monolog/monolog移除旧包，再用composer require monolog/monolog:1.2.3安装新版本。 - 或者，直接手动修改
composer.json里对应的版本号，然后运行composer update monolog/monolog（为了避免潜在的依赖冲突，建议加上--with-dependencies参数）。
需要警惕的是：如果 composer.lock 文件里还保留着旧版本的记录，那么即使你刚刚修改了 composer.json，运行 composer install 依然会安装旧版。必须通过 update 命令更新 lock 文件，或者删除 lock 文件后重新安装。
装完必须验证实际代码是不是你想要的
别完全相信 composer show 命令输出的 dev-main 或 2.x-dev 这类信息，那有可能是 Composer 错误解析了分支别名。
真正可靠的校验方式是这样的：
- 进入
vendor/monolog/monolog目录，运行git log -n1，查看最新的提交哈希（commit hash）和时间戳，是否与你目标版本的 tag 信息匹配。 - 检查
composer.lock文件中对应包的version字段（应该是"1.2.3"）和source.reference字段（应该是对应 tag 的提交哈希）。 - 留意
source.type字段：如果是dist，说明下载的是打包好的 zip 文件；如果是source，说明是从 Git 仓库拉取的源码，这时reference字段的值就至关重要了。
还有一个极易被忽略的细节：对于私有 Git 仓库，如果没有在 composer.json 的 repositories 里正确定义其类型为 vcs，那么 Composer 根本不会去查询那个私有地址，而是直接转向 Packagist 寻找，结果当然是找不到。
