不要提交 vendor 目录到 git。它是可再生的构建产物而非源码，提交会导致体积膨胀、diff 失控、合并冲突及环境不一致；应仅提交 composer.json 和 composer.lock，并通过 /vendor 正确忽略，误提交后需执行 git rm -r --cached vendor 清理缓存。
别提交 vendor 目录到 Git。它不是源码，是可再生的构建产物；提交只会带来体积膨胀、diff 失控、合并冲突，且破坏环境一致性。
为什么 vendor 一提交就出问题
常见错误现象：git diff 里全是第三方文件变更、CI 报 “Package not found”、本地能跑线上报类找不到——往往都是 vendor 被误提交或没清理干净导致的。
-
vendor含平台相关二进制（如ext-redis编译产物），Windows 和 Linux 下生成内容可能不一致 - 不同人运行
composer update后vendor差异巨大，Git 合并时几乎必然冲突 - 一个大包（比如
symfony/symfony全量）能让仓库多出 100MB+，git clone变慢，备份压力陡增 - 手动改过
vendor里的代码？下次composer install直接覆盖，修改丢失且无记录
.gitignore 里怎么写才真正生效
只加一行：/vendor（开头斜杠 + 无后缀斜杠）。
- 别写成
vendor/：旧版 Git 在子模块或嵌套路径下可能匹配不稳定 - 别写成
vendor：会意外忽略myvendor.php或vendorize这类文件 - 别加
!vendor/autoload.php：整个vendor已被忽略，这条白写了 - 验证是否生效：运行
git check-ignore -v vendor/autoload.php，应输出匹配到/vendor
已经提交了 vendor 怎么补救
改完 .gitignore 不等于解决——Git 仍在跟踪它。
- 先执行
git rm -r --cached vendor：从索引中移除，但保留本地文件（不影响当前开发） - 再
git commit -m "remove vendor from git tracking" - 之后新克隆项目的人只需运行
composer install，就能重建完全一致的vendor - 如果团队已多人误提交，建议同步清理，并在 README 里注明“请勿
git add vendor”
部署和 CI 里必须用 composer install，不是 update
composer install 读 composer.lock，composer update 改 composer.lock——这是关键分水岭。
- CI 脚本开头加一句：
test -f composer.lock || { echo "composer.lock missing"; exit 1; } - 生产环境部署用：
composer install --no-dev --optimize-autoloader - 漏提交
composer.lock是比误提vendor更隐蔽的问题：别人装出来的版本跟你本地不一样，bug 难复现 - 若报错
Your lock file does not contain a compatible set of packages，说明composer.json和composer.lock已脱节，需本地composer update并提交新 lock
真正需要 Git 管的是 composer.json 和 composer.lock，其余都是临时产物。哪怕你看到 vendor 里有几十个目录，也别手痒 git add——它越“完整”，越危险。
