vendor 目录不该进 Git，因为它是 Composer 根据 composer.json 和 composer.lock 动态生成的依赖快照，体积大、更新频繁、含平台相关二进制文件，且不同环境生成结果可能不一致，提交会导致无意义 diff、合并冲突和仓库膨胀。
vendor 目录必须被 Git 忽略，且不能手动提交；.composer 是用户级配置，与项目无关，不用管它。
为什么 vendor 不该进 Git
vendor 目录是 Composer 根据 composer.json 和 composer.lock 动态生成的依赖快照。它体积大、更新频繁、含平台相关二进制（如 ext-xxx 扩展的编译产物），且不同开发者环境可能生成略有差异的文件（比如 Windows vs Linux 的换行或符号链接）。一旦提交，会引发大量无意义 diff、合并冲突和仓库膨胀。
正确做法是只提交 composer.json 和 composer.lock —— 它们共同定义了可复现的依赖状态。
确保 .gitignore 正确屏蔽 vendor
检查项目根目录下的 .gitignore 文件是否包含以下两行（顺序不重要，但必须存在）：
vendor/ composer.lock
注意：composer.lock 通常 应该提交，所以第二行其实是反例 —— 这里故意写错来提醒你别误删。真正要加的是：
-
vendor/（末尾斜杠表示目录，防止忽略同名文件） - 可选加
composer.phar（如果你把 Composer 二进制放在项目里） - 避免写成
vendor（没斜杠）—— 可能意外忽略vendor_foo类文件名 - 如果已误提交过
vendor/，需先清理 Git 缓存：git rm -r --cached vendor，再提交
Git 集成时的典型操作流程
团队协作中，新成员克隆后必须运行安装命令，而不是期望 vendor 已存在：
- 克隆后执行：
composer install（读取composer.lock，精确还原依赖） - 不要用
composer update，除非你明确要升级依赖并更新composer.lock - CI/CD 流水线中，应在
composer install --no-dev后再构建，避免 dev-only 包污染生产环境 - 若 CI 报错 “Package not found”，先确认
composer.lock是否已提交，以及镜像源是否配置一致（如阿里云镜像需在~/.composer/config.json或项目级composer.json中声明）
关于 .composer 目录的常见误解
.composer 是 Composer 的全局用户配置目录（路径类似 ~/.composer/），存放缓存、认证令牌、全局 bin 软链等，它不属于任何项目，也不应出现在项目 Git 里。你看到它，大概率是因为：
- 误在项目根目录执行了
composer config --global ...（应去掉--global） - 用
composer create-project初始化时，模板脚本错误地把全局配置复制进了项目 - IDE 或部署脚本自动创建了该目录（比如 PhpStorm 的 Composer 插件）
只要没把它加进 Git，就无需处理；如果已误提交，删掉并加进 .gitignore 即可：
.composer/
记住：项目级配置走 composer.json 的 config 字段，用户级配置走 ~/.composer/config.json，二者绝不混用。
