指定版本号需在require后加英文冒号和版本约束，如"8.75.0"（精确版）、"^6.4"（推荐生产用，兼容6.4.0至6.x.x）、"~2.15.0"（等价于>=2.15.0且

composer require 时指定版本号的写法

直接在 composer require 命令里写死版本，是最常用也最不容易出错的方式。Composer 会按你写的约束解析并锁定对应版本。

常见写法示例：

composer require laravel/framework:"8.75.0"
composer require symfony/http-kernel:"^6.4"
composer require doctrine/orm:"~2.15.0"

注意点：

• "8.75.0" 是精确版本，只接受该 release（含 patch，不含 minor/major 升级）
• "^6.4" 表示允许 6.4.0 到 6.x.x（但不包括 7.0.0），这是推荐的生产环境写法
• "~2.15.0" 等价于 >=2.15.0 && ，适合希望控制 minor 版本范围的场景
• 双引号必须保留，否则 shell 可能错误解析 ^ 或 ~

修改 composer.json 后运行 composer update 的风险

手动编辑 composer.json 的 require 字段再执行 composer update xxx，看似灵活，但容易触发意外升级。

立即学习“PHP免费学习笔记（深入）”；

比如你把 "laravel/framework": "^8.0" 改成 "^8.75"，执行 composer update laravel/framework 后，实际装上的可能是 8.83.23——只要它满足 ^8.75，Composer 就认为合法。

更稳妥的做法是：

• 先用 composer show laravel/framework 查看当前可用版本列表
• 再用 composer require laravel/framework:"8.75.*" 锁定整个 8.75.x 分支（等价于 >=8.75.0 && ）
• 避免只改 composer.json 而不加 --with-all-dependencies，否则依赖树可能不一致

安装 dev-main 或特定分支的危险操作

用 "dev-main" 或 "dev-develop" 安装开发分支，不是“装最新版”，而是放弃版本稳定性保障。

这类写法常见于调试或等某个 PR 合并，但上线前必须替换为稳定版本号。

示例：

composer require guzzlehttp/guzzle:"dev-main#abc1234"

其中 #abc1234 是 commit hash，能稍微提升可重现性，但仍不推荐用于生产环境。

容易踩的坑：

• dev-main 没有语义化版本约束，composer update 可能拉取任意新提交，导致行为突变
• 某些包禁用了 minimum-stability 为 dev 的安装，需额外加 --stability-flags 或改全局配置
• composer.lock 里记录的是 commit id，不是 tag，CI 环境可能因网络或镜像延迟拉不到对应 commit

查看已安装包的实际版本与约束来源

当你不确定某个包为什么装了 7.2.1 而不是 7.3.0，或者怀疑被其他依赖间接锁定了版本，就该查清楚约束链。

关键命令：

composer show -t laravel/framework

输出会显示谁 require 了它、它的依赖树、以及每个层级声明的版本约束。

另一个实用技巧：

• 运行 composer depends --tree laravel/framework 查看谁在依赖它
• 检查 composer.lock 中对应包的 source 字段：如果是 "type": "git" 且含 "reference"，说明装的是 commit，不是 tag
• composer why-not laravel/framework:9.0.0 可诊断为什么无法升级到某版本（常因依赖冲突）

版本约束看着简单，真正难的是理清整棵树里谁在主导版本决策。别只盯着自己写的那一行 require。