需加 -s dev 参数启用开发稳定性策略，否则 composer 默认不解析 dev-main 等分支；私有仓库须在 repositories 中声明 vcs 类型；分支名含斜杠应原样写为 dev-feature/login；锁定 commit 哈希（如 dev-main#abc1234）可确保生产环境稳定。
composer require 装 dev-main 报 “Could not find package” 怎么办
不是命令写错了，而是 Composer 默认只查 Packagist 上的 stable 包，dev-main 这类分支名必须被显式允许解析。最直接的修复是加 -s dev 参数：
-
composer require vendor/name:dev-main -s dev—— 临时启用 dev 稳定性策略 - 若项目已设
"minimum-stability": "stable"，不加-s dev就必然失败 - 私有仓库（如 GitLab 内部库）还必须提前在
composer.json的repositories里声明"type": "vcs"，否则连源都找不到
分支名含斜杠（如 feature/login）怎么写才对
必须原样保留斜杠，不能 URL 编码，也不能替换成短横线——这是 2026 年起 Composer 原生支持的写法，旧资料里“改写为 dev-feature-login”已过时。
- 正确：
"vendor/name": "dev-feature/login"或composer require vendor/name:dev-feature/login -s dev - 错误：
dev-feature%2Flogin（多余编码）、dev-feature-login（分支名不匹配）、feature/login（缺dev-前缀） - 大小写敏感：远程仓库是
main，就不能写dev-Main；是develop，就不能写dev-dev
怎么让 dev 分支每次 install 都拉最新 commit
默认不会。Composer 把 dev-main 解析成某个 commit hash 并锁进 composer.lock，后续 install 直接复用，不 fetch。
- 加
--prefer-source：强制克隆完整 Git 仓库，而非下载 zip 包 - 删掉
vendor/name后运行composer update vendor/name（不是install） - 想彻底绕过缓存：加
--no-cache，或先composer clear-cache - 注意：
composer show vendor/name输出里的source行才是真实 commit，别只看version字段
锁定到某次提交比用分支更可靠
分支是浮动的，dev-main 今天装的是 abc1234，明天可能是 def5678。生产环境必须固定哈希。
- 写法：
"vendor/name": "dev-main#abc1234"或composer require vendor/name:dev-main#abc1234 -s dev - 哈希必须是远程分支上真实存在的 commit，否则安装失败
- 如果对方已打正式 tag（如
v2.4.0），优先用它："vendor/name": "v2.4.0"—— 更稳定、可验证、兼容性更好 -
dev-main as 2.4.0这种写法仅用于临时覆盖版本号供依赖解析，有风险，慎用
composer install 会响应 composer.json 里新写的 dev-main，其实它只认 composer.lock 里锁死的 commit。要让它生效，必须 update 或清锁重装。
