必须忽略 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 条目怎么写

只需一行，但位置和写法有讲究：

Portainer Docker Control

使用 Portainer API 控制 Docker 容器和堆栈，包括列出容器、启停/重启、查看日志以及从 Git重新部署堆栈。

下载

• 确保写在项目根目录的 .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 文件失效，导致不同环境安装出不同版本依赖。