/vendor/ 必须强制忽略，因已提交需用 git rm -r --cached vendor 解除追踪；composer.lock 是依赖快照唯一权威，必须严格维护并匹配 CI 安装参数。
vendor 目录必须忽略，不是“可选”，而是强制实践
2026 年所有主流 PHP 项目（Laravel、Symfony、WordPress 插件等）和 Composer 官方文档都明确要求：/vendor/ 必须出现在项目根目录的 .gitignore 中。这不是风格偏好，而是防止仓库失控的底线。一旦提交，后续每次 composer update 都会触发成百上千个文件变更，Git diff 失去意义，git blame 查不到真实作者，CI 日志被二进制文件刷屏。
为什么 git rm -r --cached vendor 常被漏掉或做错
很多人加了 .gitignore 却发现 Git 还在跟踪 vendor——因为该目录已被提交过。此时仅改 .gitignore 无效，必须手动解除追踪：
- 运行
git rm -r --cached vendor（注意：不带斜杠结尾，否则报错） - 确认输出里有 “rm 'vendor/xxx'” 类提示，而非 “fatal: pathspec 'vendor' did not match any files”
- 再执行
git commit -m "remove vendor from git tracking" - 如果误删了本地
vendor文件夹，别慌——composer install立刻重建
composer.lock 才是真正该盯紧的文件
忽略 vendor 的前提是：你必须提交且严格维护 composer.lock。它不是可有可无的缓存，而是依赖快照的唯一权威。常见翻车点：
- 有人删了
vendor后只运行composer install，却忘了composer.lock已过期 → 实际安装的是新版依赖，环境不一致 - 多人协作时，有人改了
composer.json但没运行composer update更新lock→ 其他人install出来的版本和预期不符 - CI 流程中用了
--no-dev，但本地lock是含 dev 依赖生成的 → 生产构建可能缺失关键工具
哪些场景真能破例？代价你得自己扛
2026 年仍极少数情况允许提交 vendor，但属于技术债务，不是捷径：
- 军工/金融内网等完全禁用外部网络的生产环境，且不允许部署时执行任何命令 → 必须把
vendor当作“只读分发物”，同时锁定所有扩展版本、禁用composer update、定期人工审计安全漏洞 - 某些老旧共享主机不支持 SSH 或 Composer 运行 → 可临时提交，但应立即规划迁移至容器化部署
- 绝对不要为“让新同事少敲一条命令”而提交 —— 自动化构建脚本或 Dockerfile 才是正解
真正容易被忽略的，是 composer.lock 的更新时机和 CI 中的安装参数匹配。它比 vendor 本身更沉默，也更危险。
