必须忽略 vendor 目录，因其是 Composer 动态生成的依赖快照，提交会导致仓库膨胀、Git 历史污染、合并冲突及 CI/CD 重复构建；标准写法为根目录 .gitignore 中添加 /vendor/；例外场景需明确承担离线部署等代价。
应该加，而且必须加。
为什么 vendor 目录不能提交到 Git
vendor 是 Composer 根据 composer.json 和 composer.lock 动态生成的依赖快照，不是源码的一部分。提交它会导致：
- 仓库体积急剧膨胀（尤其含二进制扩展或大包时）
- Git 历史污染：每次
composer update都触发大量文件变更，diff 失去可读性 - 协作冲突：多人同时更新依赖时，
vendor的二进制文件或文件权限差异极易引发合并失败 - CI/CD 重复构建：CI 环境本应从
composer.lock重装依赖，而非复用已提交的vendor
标准 .gitignore 条目怎么写
只需一行，但位置和写法有讲究：
- 确保写在项目根目录的
.gitignore中，而非子目录 - 推荐写成
/vendor/（开头加/表示仅忽略根目录下的vendor），避免误伤同名子目录 - 不要写成
vendor或vendor/（无前导斜杠），否则可能意外忽略路径中任意层级的vendor - 如果已提交过
vendor，需先执行：git rm -r --cached vendor
，再提交.gitignore更新
例外情况：什么情况下可以不忽略？
极少数封闭部署场景下可能破例，但需明确承担代价：
- 离线环境无法运行
composer install（如某些军工/金融内网），且允许将vendor当作“二进制分发物”管理 —— 此时必须锁定所有依赖版本，并禁用composer update - PHP 扩展打包工具（如
php-pm或某些 PHAR 构建流程）临时需要预编译vendor—— 但应放在构建产物目录（如build/），而非项目根目录vendor/ - 绝对不要因为“想让新人少敲一条命令”而提交
vendor；自动化 CI/CD 或 Docker 构建才是正解
真正容易被忽略的是：composer.lock 必须提交，且要和 composer.json 版本严格对齐。很多人删了 vendor 却忘了 lock 文件失效，导致不同环境安装出不同版本依赖。
