17370845950

/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 本身更沉默，也更危险。