^1.2.3 等价于 >=1.2.3 =1.2.3 =1.2.0
Composer 版本约束符号怎么写才不翻车
Composer 的版本约束不是正则，也不是模糊匹配，它是一套有优先级、有隐含规则的语法。写错一个符号，composer install 可能装上完全没测过的版本，线上直接报错。
最常踩的坑是把 ^1.2.3 当成“1.2.x”，其实它等价于 >=1.2.3 ；而 <code>~1.2.3 才是 >=1.2.3 。两个波浪号和脱字符行为完全不同，不能凭感觉换。
-
^1.2.3：允许 patch 和 minor 升级（即 1.x），但禁止 major 升级（2.0+） -
~1.2.3：只允许 patch 升级（即 1.2.x），minor 升级（1.3.0）会被拦住 -
1.2.*：等价于>=1.2.0 ，注意不是 <code>1.2.x这种写法（非法） - 省略点号如
^1或~1会触发特殊规则：^1≡>=1.0.0 ，<code>~1≡>=1.0.0 （两者此时相同）
dev-master 和 @dev 标签到底能不能用
能用，但等于主动放弃版本稳定性。只要上游 dev-master 分支一提交，你下次 composer update 就可能拉到未测试、甚至破坏性变更的代码。
真实项目里，"monolog/monolog": "dev-main" 这种写法几乎只该出现在 PoC 阶段。CI 构建失败、本地跑通线上炸锅，十次有八次是因为用了 @dev 标签却没锁哈希。
- 想跟踪开发分支？用
"monolog/monolog": "dev-main as 2.10.0"，强制 alias 成稳定版号，避免其他包因版本冲突拒绝安装 - 必须用 dev 分支时，务必在
composer.lock提交后固定 commit hash —— Composer 会自动记录，但人得确认它没被意外更新 -
@dev后缀（如"dev-main@dev"）只是告诉 Composer “允许不稳定包”，不解决实际版本漂移问题
require-dev 里的版本约束会影响生产环境吗
不会直接影响 composer install --no-dev 安装的包，但会间接影响依赖解析结果。
因为 Composer 解析整个依赖图时，require-dev 中的包和它们的约束参与统一求解。比如你在 require-dev 里写了 "phpunit/phpunit": "^10.0"，而主 require 里有个包只兼容 PHPUnit 9，Composer 就会回退或报冲突 —— 即使你线上根本不用 PHPUnit。
- CI 环境执行
composer install --no-dev时，Composer 仍会读取require-dev来做依赖兼容性检查 - 如果只想临时绕过 dev 包干扰，可用
--ignore-platform-req=phpunit/phpunit，但这是掩耳盗铃，建议修约束而非跳过 - 长期维护项目，应把测试相关依赖拆到单独的
phpunit.json或用config.platform.php模拟目标环境 PHP 版本，减少误伤
lock 文件没提交，版本约束就形同虚设
很多人以为写对了 ^ 和 ~ 就万事大吉，结果团队里 A 装的是 symfony/console v6.3.0，B 装的是 v6.3.8，C 直接上了 v6.4.0 —— 因为没人提交 composer.lock。
composer.lock 不是缓存，是**唯一可信的版本快照**。它记录了每个包的确切 commit、hash、依赖树，连 PHP 扩展要求都锁死了。没有它，^6.3.0 对每个人都是开放题。
- Git 忽略
composer.lock？立刻删掉.gitignore里的相关行 - CI 流水线执行
composer install前，先确认composer.lock存在且已更新 —— 否则等效于每次重跑update - 升级某个包时，用
composer update vendor/package --with-dependencies，而不是手改composer.json后瞎 run，否则 lock 文件可能漏锁子依赖
版本约束是方向盘，composer.lock 是刹车片。光调方向盘，车照样下悬崖。
