Composer安装dev分支时总装错版本，因其默认只选stable版，需显式指定dev-{branch-name}（如dev-main），否则会回退到最近tag或过期commit；未锁commit hash时composer update会自动拉取最新提交。
composer install dev分支时为什么总是装错版本
因为 composer require 默认只认 stable 稳定版，除非你明确告诉它“我要开发分支”。不加约束时，即使远程有 dev-main 或 dev-feature/x，Composer 也会优先选最近的 1.2.3 这类 tag 版本，甚至可能 fallback 到 dev-master（如果配置允许）但实际拉的却是过期 commit。
常见错误现象：composer require vendor/package 后发现装的是 v2.1.0，但你想用的 dev-fix-login 分支根本没出现；或者执行 composer update 后分支被自动降级成 stable 版。
- 必须显式指定分支名，格式为
dev-{branch-name}，例如dev-main、dev-develop、dev-hotfix/auth - 分支名里不能有斜杠开头，
dev-/feature/login是非法的；空格、中文、特殊符号都不行 - 如果包未在 Packagist 注册，或分支未公开（如私有 GitLab 仓库），需先在
composer.json的repositories里声明源地址
require 命令里怎么写才能装对 dev 分支
直接在命令行用 composer require 加上分支标识即可，不需要改 composer.json 再 run install —— 它会自动写入并安装。关键点是版本字符串必须以 dev- 开头，且大小写敏感（Dev-Main 无效）。
使用场景：快速验证某个 PR 是否修复了你的问题，或临时依赖一个尚未发版的功能分支。
- 装 GitHub 上的
main分支：composer require monolog/monolog:dev-main - 装带斜杠的特性分支：
composer require laravel/framework:dev-feature/sanctum-token - 装私有仓库分支（已配好
repositories）：composer require myorg/internal-sdk:dev-release/3.2 - 避免踩坑：不要写成
:dev或:dev-*，Composer 不识别通配；也不要漏掉dev-直接写main，那样它会当做一个版本号去匹配 tag
composer.json 里手动写 dev 分支要注意什么
手动编辑 composer.json 的 require 字段时，表面看只是换了个字符串，但背后会影响 lock 文件生成逻辑和后续更新行为。尤其当多个包混用 stable / dev 版本时，容易触发意外的依赖冲突。
性能影响不大，但兼容性风险明显：dev 分支没有语义化版本约束，composer update 可能拉到完全不兼容的新 commit，而 lock 文件不会像 tag 那样提供可追溯的确定性。
-
"vendor/package": "dev-main"是最简写法，但建议补上#commit-hash锁定具体提交，比如"dev-main#abc1234" - 如果分支名含点号（如
v2.5.x），必须写成dev-v2.5.x，不能省略dev-，否则 Composer 会尝试解析成版本号区间 - 不要在生产环境的
composer.json中长期保留dev-依赖，CI 构建时可能因网络或权限问题失败，尤其是私有仓库分支
装完 dev 分支后 composer update 为什么又变了
因为 composer update 默认会按 composer.json 中写的版本约束重新解析依赖图，如果分支有新 commit 推送，且你没锁 commit hash，它就会拉最新 HEAD —— 这不是 bug，是设计如此。很多人误以为 “装过一次就固定了”，其实只有带 # 的 commit 锁才真正固定。
错误现象举例：昨天 dev-main 装的是 commit a1b2c3，今天 composer update 后变成 d4e5f6，接口突然报错。
- 解决办法很简单：把
"dev-main"改成"dev-main#d4e5f6"，再跑一次composer update vendor/package - 也可以用
composer show -s vendor/package查当前解析出的 commit，复制粘贴进 json - 注意：加了
#后，composer update不会自动升级该包，除非你手动删掉#或改写成新 hash
dev 分支本身就没打算稳定，所以「装完就不管」是最容易出问题的操作。真要靠它上线，commit hash 是唯一靠谱的锚点。
