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