私有Git仓库能被Composer正确拉取，前提是：repositories必须在composer.json顶层且type为"vcs"；URL需带.git后缀并可手动git clone；包名严格匹配私有库composer.json中的name字段；分支需加dev-前缀；认证通过auth.json配置且域名精确一致；必须显式禁用packagist.org。
私有 Git 仓库能被 composer require 正确拉取，前提是 repositories 写对位置、type 设对值、URL 可直接 git clone，且认证已就绪——缺一不可。
repositories 必须在 composer.json 顶层，且 type 必须是 "vcs"
Composer 不会扫描子配置或嵌套结构。把 repositories 放进 config、scripts 或某个插件字段里，等于没写。
-
type只能是"vcs"：写成"git"、"package"或留空，Composer 都会静默跳过该仓库 - URL 必须带
.git后缀：例如https://gitlab.example.com/acme/utils.git，写成https://gitlab.example.com/acme/utils会报No valid composer.json was found - 支持 SSH 和 HTTPS 两种格式，但必须确保本地环境能用对应方式
git clone成功（可先手动试一遍）
包名必须和私有库 composer.json 中的 "name" 字段完全一致
Composer 不按 Git 路径推断包名，只严格匹配 name 字段内容。大小写、分隔符、vendor 段，差一个字符就 Could not find package。
- 假设私有库根目录
composer.json写的是{"name": "acme/utils"}，那主项目require就必须写"acme/utils": "dev-main" - 不能写成
"Acme/utils"、"acme-utils"、"utils"或漏掉acme/ - 分支名要加
dev-前缀："dev-main"可行，"main"或"*"会被当成模糊约束，去 Packagist 查，查不到就失败
认证失败往往不是 token 无效，而是位置或格式错了
Composer 对认证配置极其敏感：路径错、权限错、字段名错、域名 key 不一致，都会静默忽略，不报错也不提示。
-
auth.json必须放在全局路径：
Linux/macOS 是~/.composer/auth.json，Windows 是%APPDATA%\Composer\auth.json（不是项目根目录） - 权限必须是
600：chmod 600 ~/.composer/auth.json，否则 Composer 直接跳过 - GitLab 必须用
http-basic字段，结构为：{"http-basic": {"gitlab.example.com": {"username": "oauth2", "password": "glpat-xxx"}}} - 域名 key（如
gitlab.example.com）必须和repositories.url中的 host 完全一致，不含协议、端口、路径；gitlab.example.com:8080和gitlab.example.com是两个独立 key
默认仍会查 packagist.org，私有包常被绕过
即使你写了 repositories，Composer 默认仍优先查 packagist.org，私有源只是 fallback。结果就是：包明明存在，却报 Could not find package。
- 必须在项目级
composer.json顶层显式禁用："packagist.org": false - 这行不能嵌套、不能缩进、不能拼错，漏掉或写成
"packagist": false都无效 - 若用 Artifactory 或 Satis 作镜像，URL 末尾斜杠
/不可省略，少一个就 404
最易被忽略的一点：私有库自身 composer.json 里必须有合法的 autoload 配置，否则即使拉下来也加载不了类——这不是 Composer 安装阶段的问题，而是运行时自动加载失败，错误信息常指向类未找到，跟仓库配置无关。
