/vendor 必须加入 .gitignore，因它是平台相关、体积大且可再生的依赖目录；已提交需用 git rm -r --cached vendor 清除跟踪，并严格依赖 composer.lock 运行 composer install 保证环境一致。
必须把 /vendor 加进 .gitignore，否则团队协作和 CI 部署迟早出问题——这不是建议，是 PHP 项目的事实标准。
为什么 /vendor 不能提交到 Git
vendor 目录不是你写的代码，而是 Composer 根据 composer.json 和 composer.lock 动态生成的依赖快照。它体积大（尤其含 ext 扩展二进制）、更新频繁、平台相关（Windows/Linux 的符号链接或换行差异），且不同机器上生成的内容可能不一致。
一旦误提交，会直接导致：
- 仓库体积暴涨，克隆变慢，备份压力大
-
git diff里全是第三方文件变更，掩盖你自己的业务修改 - 多人同时
composer update后 push，vendor/合并冲突几乎必然发生 - CI 流水线拉取代码后还要清理 vendor 再重装，多走冤枉路
如何正确写 .gitignore 规则
只加一行就够了：/vendor（开头带斜杠，结尾不加斜杠）
别写成这些形式：
-
vendor/：旧版 Git 可能匹配不稳定，尤其在子模块或嵌套路径下 -
vendor：会意外忽略myvendor.php或vendorize.php这类文件 -
!vendor/autoload.php单独加这一行没意义——autoload.php 在 vendor 里，vendor 整个被忽略后它自然也不会进 Git
确认规则生效：运行 git check-ignore -v vendor/autoload.php，应输出匹配到 /vendor 这条规则。
已经提交过 vendor 怎么办
改完 .gitignore 不等于完事。Git 已经跟踪过的文件不会自动退出索引。
执行这两步：
-
git rm -r --cached vendor：让 Git “忘记” vendor，但保留本地文件（不影响当前开发） -
git commit -m "remove vendor from git tracking"：提交这次清理
之后新 clone 的人运行 composer install 就能重建 vendor，无需任何额外操作。
部署和 CI 中必须用 composer install，不是 update
composer install 读取 composer.lock，安装完全一致的依赖；composer update 会升级版本、改写 lock 文件，破坏环境一致性。
CI 脚本里推荐加参数：
-
--no-dev：跳过require-dev里的包（如 phpunit），避免污染生产环境 -
--optimize-autoloader：生成优化后的 classmap，提升加载性能 -
--no-interaction：防止卡在交互式提示上（比如 auth token 输入）
如果部署时报错 Your lock file does not contain a compatible set of packages，说明 composer.json 和 composer.lock 已脱节——这不是 vendor 的问题，是本地没跑 composer update 并提交新 lock。
真正容易被忽略的是：.gitignore 里那行 /vendor 必须在项目初始化时就存在，而不是等第一次 composer install 后再补。很多模板或脚手架（比如 Laravel 官方安装器）会自动帮你加好，但自己搭项目时，这一步得手动盯住。
