答案：根本原因是repositories配置的type与实际路径/URL不匹配，触发了强制Git检查；需检查preferred-install是否设为"source"、Git URL是否缺.git后缀、本地目录是否已git init，以及环境间Git可用性是否一致。
Composer 报 “Package is not a git repository” 或 “does not exist and is not a git repository”，根本不是它“认错了”，而是你配置的 type 和实际路径/URL 不匹配，触发了强制 Git 检查。
为什么 path 类型会要求 Git 仓库？
当你在 repositories 中写 "type": "path"，Composer 默认不强制 Git；但一旦项目或包启用了 "preferred-install": "source"（尤其全局或本地 config 中设了），它就会尝试以源码方式安装——这时会进入 Git 检测流程，哪怕你只是想软链接一个本地目录。
- 检查你的
composer.json的config.preferred-install，是否对目标包或通配符设为"source" - 进到
url指向的目录，运行git status：如果报Not a git repository，就是问题根源 - 临时绕过：在该包的
require条目后加"@dev"或显式指定稳定版本，避免触发 source fallback
Git URL 缺 .git 后缀导致驱动识别失败
Composer 判断 VCS 驱动只看 URL 结构，不查域名或内容。写成 https://github.com/user/repo 会被当成普通 HTTP 地址（type: composer），而非 Git 仓库；只有带 .git 后缀或 git@ 前缀的才走 git 驱动。
- 错误写法：
"url": "https://gitlab.example.com/group/project" - 正确写法：
"url": "https://gitlab.example.com/group/project.git"或"url": "git@gitlab.example.com:group/project.git" - 验证方法：终端中直接运行
git ls-remote -h https://gitlab.example.com/group/project.git，能返回 ref 列表才算真正可识别
本地路径存在但没初始化 Git，或权限/缓存干扰
即使 type 是 path，Composer 在首次解析时仍会尝试读取 .git 目录来提取版本信息（如 dev-main 分支名）。路径存在 ≠ Git 有效。
- 确认目标目录下有
.git/子目录；没有就进目录执行：git init && git add . && git commit -m "init" - Linux/macOS 下注意路径权限：若
url是/var/www/my-lib，确保 PHP 进程用户（如www-data）有读取权 - 缓存可能卡住旧状态：运行
composer clear-cache后再试，不要跳过这步
composer diagnose 不报错但 install 失败？环境隔离是关键
composer diagnose 在当前 shell 环境下运行，而 composer install 可能由 Web 服务、CI runner 或 Docker 容器启动——它们的 PATH、工作目录、甚至 PHP 用户都不同，Git 是否可用完全可能不一致。
- 别只信交互式终端里的
git --version；在真实执行环境中复现：比如在 CI 脚本里加which git && git --version - Docker 用户重点检查基础镜像是否装了
git（Alpine 需apk add git，Debian 需apt install -y git） - Web 环境（如 Apache+mod_php）下，用
php -r "print_r(getenv('PATH'));"查看 PHP 实际 PATH，和终端对比
最易被忽略的一点：Composer 对 path 类型的“非 Git”容忍度，取决于你有没有无意中激活了 source 安装模式。它不会主动告诉你“我打算用 Git”，只会默默失败——所以先盯住 config.preferred-install 和 URL 后缀，比反复重装 Git 更省时间。
