vendor 目录不应提交到 Git，须在 .gitignore 中显式声明 /vendor/ 和 /vendor/*；若已误提交，需执行 git rm -r –cached vendor 并提交；禁用自定义 vendor-dir，坚持默认路径以保障协作与 CI 稳定。
vendor 目录不该进 Git，这是硬性约定
Composer 的 vendor/ 目录是依赖安装产物，由 composer install 或 composer update 生成，** 不应提交到 Git**。一旦误提交，会导致仓库臃肿、合并冲突频发、CI 构建变慢，甚至暴露第三方包的敏感路径信息。
.gitignore 里必须显式忽略 vendor
很多项目初始化时漏掉这行，或只靠全局 .gitignore，但项目级配置才可靠。确保项目根目录下的 .gitignore 文件包含：
/vendor/ /vendor/*注意两点：
-
/vendor/开头的斜杠表示“项目根目录下的 vendor”，避免匹配到子目录中同名文件夹 - 加
/vendor/*是为了兼容某些 Git 版本对空目录的处理（比如已存在但为空的vendor/可能被意外跟踪） - 如果已误提交过，需先取消跟踪：
git rm -r --cached vendor，再git commit -m "remove vendor from git"
composer.json 中不要写 vendor 路径相关配置
有些开发者试图用 "config": {"vendor-dir": "my-vendor"} 改变路径，以为能绕过问题——这反而更危险：
- 新路径仍需被
.gitignore覆盖，否则只是换个名字继续污染仓库 - 团队成员若未同步该配置，
composer install会失败或混用路径 - 多数 CI/CD 流程（如 GitHub Actions）默认只认标准
vendor/，自定义路径需额外配置，增加维护成本
除非有极特殊部署约束（如共享主机限制），否则坚持用默认 vendor/ 最稳妥。
检查是否还有残留的 vendor 文件被 Git 跟踪
执行以下命令确认清理彻底：
git ls-files | grep "^vendor/"如果输出非空，说明仍有文件在索引中。常见原因：
-
vendor/曾被git add -f强制添加 -
.gitignore写成了vendor（缺末尾斜杠），导致子目录下文件仍可被跟踪 - IDE（如 PHPStorm）自动把
vendor/加入了本地 ignore 规则，但没同步到项目级.gitignore
补救方式始终是：删缓存 + 提交 ignore + 重新 install。
最易被忽略的是已提交过的 vendor/ 目录不会因新增 .gitignore 自动退出版本控制——Git 只忽略「未跟踪」的文件。只要它曾经 git add 过，就必须手动踢出索引。
