不应提交 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 <package-name> has a PHP requirement incompatible with your PHP version</package-name>—— 实际是因为你提交了在 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" <h1>正确：只提交 lock 文件，由 CI 或部署脚本还原</h1><p>$ echo "/vendor/" >> .gitignore $ git add composer.lock .gitignore $ git commit -m "lock deps, ignore vendor"</p>
真正难的不是“要不要提交 vendor”，而是理解 composer.lock 的语义边界——它保证依赖树可重现，但不保证二进制兼容性；它要求你声明 PHP 版本约束（"config": {"platform": {"php": "8.2.10"}}），而不是靠拷贝文件蒙混过关。
