composer不能直接通过require拉取任意git仓库代码，必须先在composer.json的repositories中声明type为"vcs"且url为可git clone的有效地址（如https://.../repo.git或git@...:repo.git），并确保require的包名与仓库内composer.json的name字段完全一致，否则报“could not find package”。
Composer 不能直接通过 composer require 拉任意 Git 仓库的代码——必须先在 composer.json 里声明它是哪个包、从哪来，否则必然报 Could not find package xxx at any version。
repositories 配置必须写对 type 和 url
只加 "type": "vcs" 不够，漏掉 url 或 URL 写成网页地址（比如 https://github.com/user/repo）会导致 Composer 完全无法识别源。它需要的是能被 git clone 的地址：
- HTTPS 格式：必须以
.git结尾，如"url": "https://github.com/myorg/utils.git" - SSH 格式：如
"url": "git@github.com:myorg/utils.git"，前提是本地ssh -T git@github.com能通 - 别把 Gitee/GitLab 的项目页 URL 当作 Git 地址；Gitee 可用
https://gitee.com/org/repo（Composer 会自动补.git），但 GitLab 必须写完整克隆地址 -
repositories是顶层数组，不是嵌套在config或extra里
require 的包名必须和仓库内 composer.json 的 name 字段完全一致
Composer 不按 Git 地址推导包名，只认 name 字段。常见翻车点：
- 仓库
composer.json里写的是"name": "MyOrg/utils"，但你在require里写"myorg/utils"→ 大小写不匹配，失败 - 误以为 GitHub 路径就是包名，写成
"github-user/repo-name"→ 即使 URL 对了也找不到 - 私有仓库没提交
composer.json，或文件语法错误 → Composer 解析失败，不报错但静默跳过
版本约束写法决定拉哪个 commit
分支、Tag、提交哈希全靠 require 后面的版本字符串控制，不是改 repositories.url：
- 拉
main分支："myorg/utils": "dev-main"（注意dev-前缀） - 拉
v2.1.0标签："myorg/utils": "v2.1.0"（必须已git tag v2.1.0并 push） - 拉某次提交：
"myorg/utils": "dev-main#abc1234"（#后是完整 SHA1，不是短哈希） -
dev-开头的版本默认 stability 是dev，若项目"minimum-stability"是stable，需显式加"stability-flags": {"myorg/utils": "dev"}
认证失败时 Composer 很少直接报错，而是卡住或超时
HTTPS 地址没带 token、SSH 密钥未加载、Git 凭据缓存失效，都会导致 composer install 在 “Cloning into…” 阶段停住，日志里可能只有模糊的 Could not fetch：
- HTTPS 推荐用
https://token:x-oauth-basic@github.com/...格式，token 至少要有read_repository权限 - SSH 方式更稳定，但务必确认
ssh-agent已加载密钥，且~/.ssh/config中 Host 别名配置正确 - 调试时先手动运行
git ls-remote https://.../repo.git或git ls-remote git@...:repo.git，验证底层 Git 是否通 - CI 环境慎用全局
auth.json，优先在项目级composer.json中用带认证的 HTTPS URL
最易被忽略的是：改完 composer.json 后没清缓存，composer clear-cache 再试一次——旧的失败元数据可能还在，导致反复重蹈覆辙。
