不应提交 vendor 目录，因其破坏可重现性、增大仓库体积、引发协作冲突；应仅提交 composer.lock 并通过 composer install 还原依赖，该文件已精确锁定所有包名、版本、哈希及嵌套依赖树。

因为 vendor 目录是运行时生成的、与本地环境强耦合的产物，不是项目源码的一部分——提交它会破坏可重现性、增大仓库体积、引发协作冲突，且毫无必要。

为什么 composer install 不能替代 git commit vendor/

很多人误以为“提交 vendor 能让别人不装依赖”，其实完全相反：composer install 才是标准、轻量、可验证的依赖还原方式。

• composer.lock 文件已精确锁定所有包名、版本、哈希值和嵌套依赖树，install 会严格按此还原，结果比手动拷贝 vendor 更可靠
• 不同系统（linux/macOS/windows）下某些包的二进制文件、扩展加载路径、符号链接行为不同，直接提交 vendor 可能导致他人 require 失败
• vendor 中大量小文件（尤其 node_modules 风格的嵌套结构）会让 git status、git diff 变慢，git clone 体积暴涨数倍甚至十倍

vendor 提交后最常遇到的 3 类错误

这些不是边缘情况，而是只要多人协作、跨环境部署就必然触发的问题：

• 哈希校验失败： composer install 运行时报错 Package has a php requirement incompatible with your PHP version —— 实际是因为你提交了在 PHP 8.2 下生成的 vendor，而队友用的是 PHP 8.1，但 composer.lock 里没写 PHP 约束，或约束被忽略
• Git 冲突无法自动合并： 两人同时更新了 monolog/monolog，各自 composer update 后提交整个 vendor/monolog/monolog 目录，Git 会把成百上千个文件标为冲突，根本没法手工 resolve
• docker 构建缓存失效： 即使只改了一行 src/ 代码，由于 vendor/ 在 Git 历史中频繁变更，Dockerfile 中 copy . . 会导致 FROM php:8.2-cli 的后续所有层全部重建，构建时间从 15 秒拉长到 3 分钟

哪些场景看似“必须”提交 vendor，其实有更好解法？

真有极少数受限环境（如离线生产机、老旧 CI 不支持 Composer），但仍有更干净的替代方案：

• 离线部署： 用 composer install --no-dev --prefer-dist --optimize-autoloader + composer archive 打包成单个 deps.zip，再传到目标机解压，不污染 Git
• CI 缓存加速： github Actions 可用 actions/cache@v3 缓存 ~/.composer/cache，而非把 vendor 提交进仓库；gitlab CI 用 cache: 关键字缓存 vendor/ 目录本身（仅限 CI 运行时，不出现在 Git 历史中）
• PHP 扩展缺失导致安装失败： 不要因此放弃 composer install，而应在部署文档或 .dockerfile 中明确声明依赖扩展（如 ext-pdo_mysql），或用 composer install --ignore-platform-reqs（仅调试用，上线禁用）

# 错误：把 vendor 提交进 Git $ git add vendor/ $ git commit -m "add dependencies" 
正确：只提交 lock 文件，由 CI 或部署脚本还原
$ echo "/vendor/" >> .gitignore $ git add composer.lock .gitignore $ git commit -m "lock deps, ignore vendor"

真正难的不是“要不要提交 vendor”，而是理解 composer.lock 的语义边界——它保证依赖树可重现，但不保证二进制兼容性；它要求你声明 PHP 版本约束（"config": {"platform": {"php": "8.2.10"}}），而不是靠拷贝文件蒙混过关。