/vendor必须被Git忽略，已提交的需用git rm -r --cached vendor清除跟踪；因其是composer.json和composer.lock动态生成的平台相关产物，提交会导致仓库膨胀、diff失控、合并冲突及CI低效。
vendor 目录必须被 Git 忽略，且已提交过的必须手动清除跟踪；否则协作和 CI 会持续出问题，不是“可选”，是 PHP 项目存活的基本条件。
为什么 vendor 不能进 Git
它不是源码，而是 composer.json 和 composer.lock 动态生成的产物。不同系统（Linux/macOS/Windows）下生成的符号链接、文件权限、换行符甚至扩展二进制（如 ext-redis.so）都可能不一致。一旦提交，就会：
- 让仓库体积暴涨（中等项目 vendor 轻松超 50MB）
- 每次
composer update都触发全量 diff，掩盖你自己的业务修改 - 多人同时更新后 push，
vendor/合并冲突几乎必然发生 - CI 拉代码后还得先
rm -rf vendor再重装，纯属浪费资源
.gitignore 里怎么写 vendor 规则
只加这一行就够了：/vendor（开头带斜杠，结尾不加斜杠）
- ✅
/vendor：只忽略项目根目录下的vendor目录，安全、稳定、Git 全版本兼容 - ❌
vendor/：旧版 Git 在子模块或嵌套路径下行为不稳 - ❌
vendor（无斜杠）：会意外匹配myvendor.php或vendorize这类文件 - ❌
!vendor/autoload.php：毫无意义，整个vendor已被忽略，内部文件自然不会进 Git
确认是否生效：运行 git check-ignore -v vendor/autoload.php，应输出匹配到 /vendor 这条规则。
已经提交过 vendor 怎么办
改完 .gitignore 不等于完事。Git 已经跟踪的文件不会自动退出索引。
- 执行
git rm -r --cached vendor：让 Git “忘记”它，但保留本地文件（不影响当前开发） - 执行
git commit -m "remove vendor from git tracking"：提交这次清理 - 之后新 clone 的人只需运行
composer install就能重建vendor，无需额外操作
别跳过这步——漏掉 git rm -r --cached vendor 是团队里最常重复踩的坑，导致新人克隆后 git status 依然显示一堆 vendor/ 修改未暂存。
composer install 报错“Package not found”时，真凶往往不是 .gitignore
Git 忽略 vendor/ 是正确行为，报错几乎从不因为“忽略”本身，而是下游环节断了链：
- 检查
composer.lock是否存在、JSON 格式是否合法（json_decode(file_get_contents('composer.lock'))不报错） - 确认私有包源是否在
composer.json的repositories中正确定义，且auth.json已就位 - 运行
composer diagnose，它会指出常见陷阱：比如allow-plugins拒绝了必要插件、PHP 版本不匹配、或 dist URL 返回 404 - CI 脚本开头加一句：
test -f composer.lock || { echo "composer.lock missing"; exit 1; }
真正关键的不是“看得见 vendor”，而是 composer.lock 是否完整、可信、且所有环境都能访问它记录的每个包源——这点比 .gitignore 写得再漂亮都重要。
