vendor/ 必须加进 .gitignore，composer.lock 必须提交到仓库——这是 Composer 官方强制推荐的协作规范；vendor/ 是动态生成的依赖集合，体积大、易冲突、环境耦合强，而 composer.lock 锁定确切版本，保障环境一致性和可复现性。
直接说结论：vendor/ 必须加进 .gitignore，composer.lock 必须提交到仓库——这是 Composer 官方强制推荐的协作规范，不是可选项。
为什么 vendor/ 不能提交到 Git
因为 vendor/ 是纯生成物：它由 composer install 或 composer update 根据 composer.json 和 composer.lock 动态拉取并解压的依赖包集合。它的体积大（常达百 MB）、内容频繁变动、且与本地环境强耦合（如扩展、PHP 版本差异可能影响部分包的构建结果）。
常见错误现象包括：
- 多人协作时反复出现
vendor/的冲突合并，毫无意义 -
git status长期显示大量未跟踪文件，干扰真实代码变更 - CI 构建因误用本地
vendor/而跳过依赖安装，导致环境不一致
正确做法是确保 .gitignore 中有这一行：
vendor/
注意末尾斜杠，表示忽略整个目录；不要写成 vendor（会漏掉同名文件），也不要写成 vendor/*（无法递归忽略子目录）。
为什么 composer.lock 必须提交
composer.lock 是锁定所有依赖确切版本（含嵌套依赖）的快照文件。没有它，composer install 会退化为 composer update 行为，每次拉取的依赖版本都可能不同，导致“在我机器上能跑”的经典问题。
使用场景明确：
- CI/CD 流水线执行
composer install时，必须读取composer.lock才能复现开发环境 - 团队新成员克隆仓库后，运行
composer install才能获得与你完全一致的vendor/ - 线上部署脚本依赖
composer.lock保证生产环境依赖原子性
如果历史误提交过 vendor/，需先清理 Git 缓存：
git rm -r --cached vendor/
再提交一次，确保后续 git status 不再列出 vendor/ 下任何文件。
其他 Composer 相关文件的处理建议
除核心两项外，以下文件也常被问及：
-
composer.phar：一般不提交。应通过curl -sS https://getcomposer.org/installer | php或系统包管理器安装，避免二进制文件污染仓库 -
composer.json.dist：仅在项目模板中存在，用于生成初始composer.json，本身不参与依赖管理，可忽略或按需保留 -
vendor-bin/（如使用roave/security-advisories等工具）：和vendor/同理，应加入.gitignore
典型 .gitignore 片段如下：
vendor/ vendor-bin/ composer.phar *.lock !composer.lock
最后一行 !composer.lock 是关键：它显式取消对 composer.lock 的忽略（即使前面有 *.lock），避免误伤。
最容易被忽略的是 !composer.lock 这个例外规则——很多人加了通配符 *.lock 后忘了放行，结果把 composer.lock 也忽略了，导致协作时依赖版本失控。检查方法很简单：运行 git check-ignore -v composer.lock，输出应为空，否则说明它被意外忽略了。
