composer require 包名 版本号（空格分隔），支持精确版如2.9.0、~2.9、^2.9、dev-main等；dev分支需加dev-前缀；版本仅为建议，composer按依赖兼容性自动调整。
composer require 怎么指定具体版本号
直接在包名后面加 version，用空格分隔，不是等号也不是冒号。Composer 会按语义化版本规则解析，但你写什么它就尝试装什么——除非冲突，否则不自动升/降级。
常见错误是写成 composer require monolog/monolog=2.9.0 或 monolog/monolog:2.9.0，这两种都报错。正确写法只有一个：composer require monolog/monolog 2.9.0
- 支持的版本格式包括：精确版本（
2.9.0）、波浪号（~2.9）、插入符（^2.9）、分支别名（dev-main） - 如果项目已存在该包，
require会尝试升级/降级；想强制重装指定版，加--update-with-dependencies更稳妥 - 注意：写
2.x这种模糊写法，实际匹配的是^2.0，不是“任意 2 开头的版本”，这点很多人误判
安装 dev 分支或特定 commit 怎么写
dev 分支本质是别名，不是稳定版本，必须显式带上 dev- 前缀，否则 Composer 当作普通版本号处理并报错 Could not find package。
比如要装 gitHub 上 main 分支最新代码：composer require vendor/package dev-main；装某个 commit：composer require vendor/package dev-main#abc1234。
- commit hash 必须跟在分支名后，用
#连接，不能单独写abc1234 - 如果目标仓库没配置
repositories，私有 Git 仓库需先在composer.json里声明类型为vcs -
dev-开头的版本不会进composer.lock的packages列表，而是出现在packages-dev，上线前务必检查是否误用了 dev 版本
为什么指定了版本却装了别的版本
根本原因：Composer 解析版本时优先满足依赖图整体兼容性，不是无条件照单全收。你写的版本只是“建议”，不是“指令”。
典型现象是执行 composer require foo/bar 1.2.3 后，实际装了 1.2.5，甚至 2.0.0——说明其他已装包要求更高版本，或者 foo/bar 的 1.2.3 本身依赖一个你项目里已存在的、无法降级的包。
- 运行
composer why-not foo/bar:1.2.3查看具体冲突点 - 用
composer prohibits foo/bar:1.2.3找出哪个包挡了路 - 如果硬要锁死，得配合
composer require foo/bar:1.2.3 --no-update再手动composer update foo/bar，但大概率失败，不如先理清依赖链
全局配置影响版本解析吗
不影响 require 的版本写法，但会影响最终能否成功安装。比如 minimum-stability 设为 stable 时，你写 dev-main 就会失败；设为 dev 才允许。
另一个关键是 prefer-stable：即使你写了 ^2.0，如果同时存在 2.0.0-beta 和 2.0.0，开启该选项才会选后者。
- 这些配置都在
composer.json根对象下，不是命令行参数 -
minimum-stability默认是stable，所以不加dev-前缀的分支名一定失败 - 修改配置后必须运行
composer update --lock才生效，require不会自动 reload 配置
版本指定看着简单，真正卡住人的永远是依赖树里的隐性约束——不是你没写对，而是别人写死了你绕不开。动手前先 composer show 看一眼现有包范围，比反复试错快得多。