应设 "minimum-stability": "stable"，仅对必需开发版的包显式加 @dev 后缀；避免全局设 dev 或依赖 prefer-stable 兜底，须用 as 别名、--dry-run 验证及锁文件检查确保确定性版本。
如何设置 minimum-stability 才不踩坑
全局设成 dev 看似能解决安装失败，实则埋下隐患：所有依赖都可能被解析为不稳定分支，composer.lock 会记录 dev-main 这类无固定哈希的引用，导致部署时拉取到非预期代码。真正安全的做法是保持 "minimum-stability": "stable"，仅对明确需要开发版的包单独加 @dev 后缀。
常见错误现象：运行 composer install 报错 Could not find package xxx at version yyy，本质是 Composer 按默认稳定性过滤掉了 dev 分支，而非包不存在。
- 优先用
"require": { "vendor/pkg": "dev-main as 1.2.3" }显式 alias，把分支映射成语义化版本 - 避免
"minimum-stability": "dev"+"prefer-stable": true的组合——它仍可能在解析依赖链时引入dev版本 - 执行
composer update --dry-run vendor/pkg验证解析结果，确认最终锁定的是稳定版还是分支
prefer-stable 是开关，不是保险丝
prefer-stable 不改变约束逻辑，只影响“多个候选版本满足同一约束时选哪个”。比如 "monolog/monolog": "^3.0" 同时有 3.5.0（stable）和 3.6.0-RC1（RC），它会让 Composer 选 3.5.0；但如果 3.5.0 被 conflict 规则排除，它不会跳过 RC 去找更老的 stable 版。
性能影响很小，但误以为它能兜底会导致线上出问题：某次 composer update 后，日志组件突然降级到 2.x，只因新 stable 版本与另一个包冲突，而 prefer-stable 没法绕过这个冲突。
立即学习“PHP免费学习笔记（深入）”；
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须配合
composer show monolog/monolog查看实际可选版本范围 - 升级关键包前，先跑
composer prohibits vendor/pkg确认有没有隐性冲突 - 不要依赖它来“自动规避不兼容”，它不解决根本约束矛盾
单个包的 @stable/@dev 后缀怎么写才生效
后缀必须紧贴版本字符串，中间不能有空格，且只作用于该行声明。写成 "vendor/pkg": "^2.0 @dev" 无效，正确是 "vendor/pkg": "^2.0@dev" 或 "vendor/pkg": "dev-main"。
容易忽略的细节：如果包本身 require 了另一个不稳定的包，你的 @dev 并不会传导下去——子依赖仍受全局 minimum-stability 限制。这时要么给子依赖也加后缀，要么用 repositories 替换源。
-
@stable在大多数场景冗余，因为 stable 是默认行为 -
@RC和@beta适合测试新特性，但需人工验证 CHANGELOG 中的 breaking change - 使用
composer depends vendor/pkg反查谁拖进了不稳定的依赖链
为什么 composer.lock 里有时出现 dev-main，有时是具体 commit
这取决于包的版本发布方式。若包作者打了 v1.2.3 tag，Composer 锁定的是 tag 对应的 commit；若只推了 main 分支没打 tag，且你用了 dev-main，锁文件就存分支名——下次 composer install 会拉最新 commit，行为不可控。
真正可靠的锁定，永远基于确定性标识：tag、commit hash 或带 as 别名的分支。看到锁文件里有 "reference": "dev-main" 就该警觉，说明没做版本映射。
- 强制要求团队禁止直接写
dev-main，改用"dev-main as 1.2.3" - CI 流程中加入检查：
grep -q '"reference": "dev-' composer.lock && exit 1 - 用
composer show --tree快速扫一遍是否有未映射的 dev 引用
