Composer默认用^约束版本，如"2.8.0"等价于"^2.8.0"，允许2.8.x至2.9.x；精确锁定需写"=2.8.0"或"==2.8.0"；"^2.8.0"允许2.8.0–2.9.999但不升级到3.0.0；"~2.8.0"等价于>=2.8.0。
composer.json 里怎么写版本号才生效
Composer 不是直接认你写的“1.2.3”就装那个版本，它默认用 ^（脱字符）做隐式约束。比如写 "monolog/monolog": "2.8.0"，实际等价于 "^2.8.0"，会允许安装 2.8.x 甚至 2.9.x（只要不跨主版本）。想锁死精确版本，必须加 = 前缀："=2.8.0"；想禁用所有自动升级，用 ==（双等号）更稳妥。
-
"^2.8.0"→ 允许 2.8.0 到 2.9.999，但不会升到 3.0.0 -
"~2.8.0"→ 等价于>=2.8.0 ，只允许补丁级更新（2.8.x） -
"2.8.*"→ 同~2.8.0，但语义模糊，不推荐 -
"dev-main"或"dev-develop"→ 拉取分支最新提交，不稳定，CI/CD 中慎用
为什么 composer update 还是装了新版本
常见原因是 composer.lock 文件没被提交或被忽略，导致团队成员执行 composer install 时重新解析依赖树。另一个高发场景：你改了 composer.json 的版本约束，但没删 composer.lock 或没运行 composer update vendor/package-name 单独更新——Composer 会优先尊重 lock 文件里的已解析版本。
- 检查
composer.lock是否存在且未被.gitignore排除 - 确认修改后运行的是
composer update monolog/monolog，不是仅composer install - 如果想强制重算全部依赖，先删
composer.lock再composer install（生产环境禁止）
使用 composer show 验证实际安装版本
composer show 显示的是当前 vendor/ 下真实安装的版本，比看 composer.json 更可靠。加 -s 参数还能看到该包依赖了哪些其他包及其版本约束。
composer show monolog/monolog # 输出类似： name : monolog/monolog versions : 2.8.0, 2.9.1, 3.0.0 type : library license : MIT License (MIT) (OSI approved) ...
注意：输出中的 versions 是该包在 Packagist 上**所有可用版本**，不是你本地装的。要看本地装的哪个，得看 composer show monolog/monolog -i（-i 表示 installed）。
私有包或 Git 仓库怎么指定 commit / tag
当包不在 Packagist，而是通过 Git URL 引入时，版本号其实是 Git 的 ref 名称。这时不能写语义化版本号，得用 dev- 前缀或直接写 tag 名。
{
"require": {
"myorg/my-private-lib": "dev-main",
"myorg/my-private-lib": "v1.2.0",
"myorg/my-private-lib": "dev-feature/login#abc1234"
}
}-
v1.2.0必须是 Git 仓库中真实存在的 tag，否则报Could not find package ... matching version -
dev-main对应main分支 HEAD，每次composer update都可能变 -
dev-feature/login#abc1234表示固定到某个 commit，最稳定，但无法享受自动安全更新
通配符本身不复杂，真正容易出问题的是约束意图和 lock 文件状态之间的错位。别只盯着 composer.json 写了什么，多跑一遍 composer show -i，再对比 composer.lock 里对应项的 source 和 dist 字段，才能确认到底装了哪个 commit。
