根本解法是让Composer不走Git流程，优先用composer install --prefer-dist或配置preferred-install: "dist"；.git残留因--prefer-source或path仓库导致，前者可禁用，后者需清理或改发布方式。
vendor 目录里出现 .git 文件夹，composer install 就可能报 fatal: not a git repository ——这不是网络问题，是 Composer 误判了目录状态。根本解法不是删文件，而是让 Composer 别去碰 Git。
为什么 .git 在 vendor 里会出错
Composer 默认对 VCS 包（比如 GitHub 上的包）会尝试用 git rev-parse 检查本地仓库状态。一旦某个 vendor/xxx/yyy/.git 存在但不完整（比如手动 clone 过、或上次用了 --prefer-source 后残留），它就会执行失败命令，直接中断安装。
- 错误典型输出：
fatal: not a git repository (or any of the parent directories): .git或Unable to locate a valid git directory - 不是所有包都会触发——只影响那些被识别为 “source 安装态” 的子目录
-
path类型仓库不受--prefer-dist控制，只要源路径含.git，就会原样复制进来
怎么确认是不是 --prefer-source 导致的
先看全局和本地配置是否强制走 source：
Git post-commit 钩子 + SQLite 提交索引工具。自动将每次提交的元数据（哈希值、作者、分支、仓库、主题）记录到本地 SQLite 数据库中，随后提供一个命令行接口（CLI），支持查询、列表展示、统计、删除和更新记录。 触发场景：管理 Git 钩子、跨仓库查询提交历史、定位某次提交所属的仓库、查看提交统计信息、将提交记录写入本地索引。 当用户提及“提交日志记录”、“提交索引”、“跨仓库查找提交”、“Git 钩子管理”，或希望以结构化方式查询其提交历史时（即使未明确指出该工具），请使
- 运行
composer config --list | grep preferred-install，如果输出preferred-install: {"*": "source"}，就坐实了 - 再验证具体包：
ls -la vendor/myvendor/mypackage/.git—— 能列出内容，说明它是 clone 来的；zip 方式安装则该目录根本不存在 - 临时加
-v参数重跑：composer install -v，日志里通常带出出问题的包路径，比如Cloning into 'vendor/foo/bar'...那行之后立刻报错
用 --prefer-dist 绕过 Git 操作
这是最轻量、最安全的应对方式：跳过克隆，改用预打包的 zip/tar.gz 发布包，自然不依赖 .git。
- 下次安装直接加参数：
composer install --prefer-dist - 想永久生效（当前项目）：
composer config preferred-install "dist"，会写入composer.json的config字段 - 全局禁用（慎用）：
composer config --global preferred-install "dist" - 注意：它对
path仓库无效——这类本地包的.git只能靠清理或换发布流程解决
手动清理 .git 的风险点
虽然 find vendor -name ".git" -type d -exec rm -rf {} + 能快速清掉，但容易埋坑：
- 下次执行
composer update --prefer-source或配置没改回来，.git会立刻重现 - CI 环境中若未统一配置，不同机器行为不一致，导致部署结果不可控
- 如果误删了你真需要的调试信息（比如要
git blame查某行来源），就得不偿失 - 更隐蔽的问题：某些包的
install脚本（如scripts中的post-install-cmd）可能依赖.git目录存在，删完反而引发新错误
真正关键的不是“删不删”，而是“谁在控制安装方式”。--prefer-dist 是开关，preferred-install 是策略，而 path 仓库是例外——这三者边界不清时，.git 就成了定时炸弹。
