vendor目录不应提交到Git，应通过.gitignore忽略并提交composer.lock确保依赖一致，避免仓库膨胀和环境差异。

在使用 Composer 管理 PHP 项目依赖时，vendor 目录的版本控制策略是一个常见但容易被误解的问题。正确处理 vendor/ 和 .gitignore 能避免团队协作中的依赖冲突、仓库膨胀和部署问题。

vendor 目录是否应该提交到 Git？

通常情况下，不应该将 vendor 目录提交到版本控制系统（如 Git）。原因如下：

• 体积大：vendor 包含所有第三方库，会使仓库迅速膨胀。
• 可复现性差：直接提交 vendor 可能导致不同环境依赖版本不一致。
• 维护困难：更新依赖时需手动替换整个目录，容易出错。

相反，应通过 composer.json 和 composer.lock 文件来声明和锁定依赖版本。

推荐的 .gitignore 配置

在项目的根目录 .gitignore 文件中添加以下内容：

/vendor
!vendor/.git

说明：

• /vendor 忽略整个 vendor 目录。
• !vendor/.git 是一个例外规则，防止忽略子模块或私有包中可能存在的 .git 目录（如果你通过 VCS 方式加载某些包）。

注意：大多数情况下，vendor 下的包不应包含自己的 .git 目录，因为 Composer 默认使用 dist 包。但如果使用 vcs 类型源并启用 fallback 或开发模式，保留该例外更安全。

确保依赖一致性：提交 composer.lock

必须将 composer.lock 提交到 Git。这个文件锁定了每个依赖的具体版本和哈希值，确保：

• 团队成员运行 composer install 时安装完全相同的依赖树。
• 生产环境与开发环境依赖一致。
• CI/CD 流程可重复构建。

如果没有 composer.lock，每次执行 composer install 都可能安装新版本（即使 minor 或 patch），增加意外变更风险。

特殊情况处理

某些场景下可能需要调整策略：

• 离线部署或无网络环境：可考虑将 vendor 提交，但应明确标注用途，并定期更新，不推荐常规使用。
• 私有包嵌入：如果私有包以 git submodule 形式存在于 vendor 中，确保 .git 不被误删，可通过精细的 .gitignore 规则控制。
• Docker 构建优化：利用 composer install --no-dev 在构建镜像时安装生产依赖，无需提交 vendor。

基本上就这些。标准做法是：.gitignore 掉 vendor，提交 composer.json 和 composer.lock，让 Composer 负责依赖安装。这样既轻量又可靠。