默认情况下 Composer 跳过 dev-master 等开发版，需通过 “minimum-stability”: “dev” 全局放宽，或对特定包用 “vendor/package”: “dev-master as 1.0.0” 精准控制；配合 “prefer-stable”: true 可优先稳定版、无稳定版时才退选 dev 版。
怎么让 composer install 装上 dev-master 这类不稳定版本
默认情况下，Composer 会跳过 dev- 开头的分支或 dev-master 这类开发版，只装 stable（即 stable、RC、beta 等标记明确的版本）。想装 dev-master，得主动放宽策略。
- 在
composer.json里加"minimum-stability": "dev"—— 这会让整个项目允许安装所有dev-分支，但副作用是：所有依赖都可能被升级到不稳定的开发版，容易翻车 - 更稳妥的做法是只对特定包放宽：用
"require"中的版本约束写成"vendor/package": "dev-master as 1.0.0"或"dev-main as 2.0.0"，这样其他包仍走默认稳定策略 - 如果只是临时试一个包，直接运行
composer require vendor/package:dev-main，Composer 会自动把该包设为dev-main并写进composer.json，同时保持全局minimum-stability不变
minimum-stability 和 prefer-stable 怎么配合用才不踩坑
minimum-stability 是底线，prefer-stable 是偏好——两者不是互斥，而是协同生效。很多人只改了前者，结果一堆 dev- 包被拉下来，CI 直接挂掉。
-
"minimum-stability": "dev"+"prefer-stable": true：Composer 会优先选稳定版，但当某包没有稳定版可选时（比如你写的内部私有库还没打 tag），才退而求其次用dev-分支 - 反过来，
"minimum-stability": "stable"时，哪怕写了"prefer-stable": false，也装不上dev-master—— 因为底线卡死了，偏好没机会生效 - 常见错误：CI 环境里没配
prefer-stable，又用了minimum-stability: dev，结果每次composer install都随机装不同 commit 的dev-版本，构建不可重现
为什么 composer require vendor/pkg:dev-main 有时不生效
不是命令写错了，而是 Composer 在解析版本时被其他约束拦住了。最典型的是已存在冲突的锁文件或历史依赖。
- 先删
composer.lock再跑require—— 否则 Composer 可能沿用旧的解析结果，尤其当锁文件里已有该包的稳定版记录 - 检查有没有
conflict或replace规则间接禁止了dev-版本，比如某个依赖声明了"conflict": {"vendor/pkg": "，而 <code>dev-main没带 version hint，会被当成0.x被挡掉 - 某些私有仓库（如 Satis、Private Packagist）没正确配置
dist信息，导致 Composer 认为dev-main不可用，降级失败后静默跳过 —— 此时看composer require -v的输出，会看到Skipped branch dev-main类提示
装完 dev- 版本后，怎么确保团队和 CI 行为一致
靠人记不住，靠文档留不住，唯一可靠的是锁文件 + 明确的 commit pin。
- 执行完
composer require后，立刻提交composer.lock—— 它会记录具体 commit hash，而不是模糊的dev-main，这才是可复现的关键 - 避免在
composer.json里写"dev-main"这种无 hash 的引用；如果必须，至少补上as别名，例如"dev-main as 2.1.0"，防止后续composer update自动切到新 commit - CI 脚本里别用
composer install --no-lock，否则即使本地锁了，CI 还是会重新解析，可能拉到不同dev-提交
稳定性和灵活性之间没有银弹，dev- 版本本质是“临时借用”，真正要长期用，就得打 tag 或改用 path repo 本地链接——否则迟早有人在半夜收到 Slack 报警说“生产环境崩了，因为 dev-main 今天被 push 了一个 break change”。
