不提交 vendor 目录的核心原因是它会增大仓库体积、干扰代码审查、引发合并冲突且违背 Composer 依赖管理原则；正确做法是提交 composer.json 和 composer.lock，通过 .gitignore 忽略 /vendor，并在部署时运行 composer install 以确保环境一致性。
将 vendor 目录提交到 Git 是一个常见的新手误区。强烈不建议这样做的核心原因在于：vendor 目录包含的是项目依赖的第三方库，这些库本应由 Composer 自动管理，而不是手动维护。
为什么不应该提交 vendor 目录？
1. 体积庞大，拖慢仓库
vendor 目录通常包含几十甚至上百个第三方包，使得代码库体积急剧膨胀，影响克隆、拉取和备份速度。
2. 难以追踪真正变更
当 vendor 被提交后，每次依赖更新都会产生大量文件变更，掩盖了你自己写的业务代码修改，让 git diff 和 code review 变得混乱。
3. 版本冲突风险高
多人协作时，如果各自更新了不同的依赖，合并 vendor 文件极易引发冲突，解决起来耗时且危险。
4. 违反依赖管理原则
现代 PHP 项目使用 Composer 来声明和管理依赖，真正的依赖信息其实在 composer.json 和 composer.lock 中，而不是 vendor 本身。
Composer 是如何解决这个问题的？
Composer 通过两个关键文件来确保项目在不同环境中能还原出一致的依赖：
- composer.json：声明项目需要哪些包及其版本约束
- composer.lock：记录当前安装的每个依赖的具体版本号（精确到 commit 或 release）
当你在新环境运行 composer install 时，Composer 会读取 composer.lock 文件，并安装完全一致的依赖版本，从而保证所有开发者和生产环境使用相同的第三方代码。
简单易用的 GitCode API SKILL，提供 CLI 和轻量级 Python SDK 两种调用方式，用于与 GitCode 的 REST API 进行交互。支持加密访问令牌、异步调用以及完善的类型提示。 - 文档：https://gitcode-api.readthedocs.io/ - PyPI 页面：https://pypi.org/project/gitcode-api - GitHub 仓库：https://github.com/Trenza1ore/GitCode-API
而 composer update 则用于主动升级依赖，它会根据 composer.json 的版本规则尝试获取新版本，并生成新的 lock 文件。
标准做法是什么？
1. 将 composer.json 和 composer.lock 提交进 Git
2. 在 .gitignore 中添加 /vendor
3. 部署时运行 composer install（不要用 update）
这样既保证了依赖可重现，又避免了 vendor 目录带来的各种问题。
基本上就这些。
