<p>匹配所有 2.x 版本应写为 ^2，它等价于 >=2.0.0 <3.0.0；^2.3 等价于 >=2.3.0 <3.0.0；而 2.* 和 ~2 均不符合 Composer 的语义化版本约束规范。</p>
composer 不支持 shell 风格的通配符（比如 * 或 %），你写 "monolog/monolog": "1.*" 会直接报错：`Invalid version string "1.*"`。所谓“通配”，其实是靠语义化版本约束操作符实现的范围匹配。
怎么写才能匹配所有 2.x 版本？
用 ^2，不是 2.*，也不是 ~2。
-
^2等价于>=2.0.0 ，这是最常用、最安全的“主版本锁死”写法 -
~2.3是错的——它会被当作>=2.3.0 ，但语义上本意是“允许修订版升级”，所以应写 <code>^2.3（等价于>=2.3.0 ）或更精确的 <code>~2.3.0（等价于>=2.3.0 ） -
2.*是非法语法，Composer 解析失败；2.x同样无效 - 想兼容多个主版本？用
^1.0 || ^2.0，但要注意：这不等于“任意 1.x 或 2.x”，而是让 Composer 在满足任一约束的版本中选一个（可能最终装的是2.9.1，跳过所有 1.x）
为什么 composer update 还是装了新版本？
因为 composer.lock 文件在起作用，不是版本约束没生效。
- 你改了
composer.json里的版本号（比如从"^1.2"改成"^1.3"），但没运行composer update monolog/monolog，Composer 就继续按lock里旧的解析结果装包 -
composer install永远以composer.lock为准，完全忽略composer.json的约束变更 - 检查实际装的是哪个版本？别看
composer.json，运行composer show monolog/monolog -i（-i表示 installed） - 团队协作时，
composer.lock被.gitignore了，或者没提交——这是最常见、最隐蔽的“版本漂移”根源
私有包或 Git 仓库怎么“通配”最新提交？
这不是版本约束问题，而是源配置问题；dev-main 不是通配符，是分支引用。
-
"myorg/lib": "dev-main"→ 拉取main分支最新 commit，版本号显示为dev-main#abc123，每次composer update都可能变 -
"myorg/lib": "v1.2.0"→ 必须是 Git 仓库里真实存在的 tag，否则报Could not find package -
"myorg/lib": "dev-feature/login#abc1234"→ 指定具体 commit，可重现，但无法自动更新 - CI/CD 中慎用
dev-分支，构建不可重现；如需“最新稳定”，应在 Git 里打语义化 tag，然后用^1.2这类约束
composer 的“灵活”是有代价的：越宽松的约束（比如 ^2），越容易在某次 update 中引入行为变化；越精确的写法（比如 =2.8.0 或 ==2.8.0），越难满足依赖树。真正关键的不是怎么写得“看起来灵活”，而是清楚哪一层该锁、哪一层可放——这得看你的发布节奏和下游依赖是否可控。 
