根本原因是composer.lock仍记录旧分支commit hash或vendor残留旧代码，Composer不覆盖已安装包；须删除vendor和composer.lock后重运行composer install。
composer install 仍拉取 master 而非 dev-feature 分支
根本原因不是版本写错了，而是 composer.lock 里还存着旧分支的 commit hash，或者 vendor/ 下残留了旧代码。Composer 不会主动覆盖已安装的包，哪怕 require 字段已改成 "dev-feature/login"。
必须执行以下三步清理再重装：
- 删掉
vendor/目录（不能只删子目录） - 删掉
composer.lock - 运行
composer install（不是update），让 Composer 从头解析依赖树
如果仍失败，检查分支名是否完全匹配远程仓库——dev-feature/login 和 dev-feature-login 是两个不同分支，大小写也敏感（main ≠ master）。
私有 Git 仓库配置后依然报 403 或 “Repository not found”
这说明 Composer 根本没走到克隆那步，卡在认证或仓库发现阶段。常见陷阱有：
-
repositories字段漏了"type": "vcs"，只写了 URL —— Composer 会直接跳过该条目 - URL 没以
.git结尾（如https://bitbucket.org/xxx/yyy必须改为https://bitbucket.org/xxx/yyy.git） - GitHub/GitLab 私有库未配 token：
auth.json里没写github-oauth.github.com或gitlab-oauth.gitlab.com对应的 token - SSH 方式未启用 agent 转发（CI 场景下尤其容易漏），或
url写成git@github.com:xxx/yyy却没配 SSH key
验证方式：运行 composer config -v，看输出里是否列出你配置的仓库；再执行 composer show -a vendor/package，若返回空或报错，说明仓库未被识别。
dev-main#abc1234 安装失败并提示 “Could not find package at commit abc1234”
这个错误和网络无关，是本地 lock 文件与远程状态脱节导致的。因为 dev-main#abc1234 是“浅层锁定”，不校验 commit 是否存在、是否被 force-push 覆盖。
一旦远程分支上该 commit 被覆盖（例如 rebase 后推送到 main），本地 composer.lock 里记录的 hash 就失效，下次 install 必然报错。
更稳妥的做法是：
- 改用
"dev-main"（无 hash），让 Composer 每次拉取 HEAD —— 适合 CI/CD 流水线 - 若必须锁死某次提交，优先用 Git tag +
1.2.3@dev形式，并确保 tag 已git push --tags到远程 - 绝对不要在生产环境长期依赖
#commit-hash，它不具备语义稳定性
composer create-project 拉不到私有仓库的 dev 分支
create-project 默认只查 Packagist，不会自动读取你项目里的 repositories 配置。所以即使你本地 composer.json 已配好私有源，create-project 也看不到。
正确做法只有两种：
- 先用
git clone拉下私有仓库，再进目录执行composer install - 在
create-project命令中显式加--repository参数，例如：composer create-project --repository='{"type":"vcs","url":"https://gitlab.com/xxx/yyy.git"}' xxx/yyy my-app "dev-main"
注意：--stability=dev 只解决稳定性限制，不解决仓库不可见问题；show -a 也查不到私有库，除非提前配好认证和 repositories。
