vendor 不该提交到 Git，因其是依赖产物而非源码，体积大、更新频繁、含平台相关二进制，导致仓库臃肿、diff 失控、合并冲突高发；composer install 用于部署和协作，精确还原 composer.lock 锁定版本，composer update 仅用于开发阶段主动升级依赖。
为什么 vendor 不该提交到 Git
因为 vendor 是依赖的产物，不是源码。它体积大、更新频繁、含平台相关二进制（如 ext-redis 扩展的编译结果）、且不同环境（Linux/macOS/Windows）下可能生成不一致的文件。Git 提交 vendor 会导致仓库臃肿、diff 失控、合并冲突高发，违背 Composer 的设计初衷。
composer install 和 composer update 用哪个？
上线部署或团队协作拉代码后，必须用 composer install —— 它只读取项目根目录下的 composer.lock 文件，精确还原当时锁定的包版本与哈希值，确保所有环境行为一致。
而 composer update 会忽略 composer.lock，重新解析 composer.json 并升级到满足约束的最新版本，只应在开发阶段主动更新依赖时使用。
从 Git 仓库历史中彻底删除文件
下载
|Git删除了文件，但还会在Git 仓库历史中遗留。 - 想要从 Git 历史移除敏感信息（密码、密钥、token、私钥） - 想要删除意外提交的大文件 - 想要重写 Git 历史、移除特定文件的所有痕迹 - 提到 "force push"、"重写 commit 历史" - 需要从所有分支、所有 tag 中删除某个文件
- CI/CD 流水线、Docker 构建、新同事 clone 后：一律执行
composer install - 本地开发中想尝鲜新版本或修复安全漏洞：先
composer update vendor/package-name，再提交更新后的composer.lock - 若误删了
composer.lock，运行composer install会报错；此时应从 Git 恢复它，而不是直接composer update
如何保证 composer.lock 始终可靠？
composer.lock 是环境同步的唯一可信依据，但它本身容易被忽略或破坏：
- 必须提交到 Git —— 它不是临时文件，是“依赖快照”的权威记录
- 每次
composer install或composer update都会校验并写入 SHA256 哈希，防止篡改 - 若多人协作中出现
composer.lock冲突，不要手动编辑，应先git checkout --ours composer.lock，再运行composer update --lock重新生成（前提是双方已同步composer.json变更） - Docker 中建议加一句
RUN composer install --no-dev --optimize-autoloader，避免 dev 依赖污染生产环境
常见同步失败现象和对应检查点
当 composer install 在某台机器上失败，但其他机器正常，优先排查以下几项：
- PHP 版本是否匹配？查看
composer.json中"config": {"platform": {"php": "8.1.0"}}或"require": {"php": "^8.1"}，用php -v核对 - 扩展是否缺失？如报错
The requested PHP extension ext-zip * is missing from your system，需安装系统级依赖（Ubuntu:sudo apt-get install php-zip） - 权限问题？
vendor/目录被残留文件占用或属主不对，可先rm -rf vendor composer.lock，再git checkout composer.lock，最后composer install - 镜像源失效？国内用户常配阿里云或腾讯云镜像，若突然超时，临时切回官方源：
composer config -g repo.packagist composer https://packagist.org
最易被忽略的是：有人在 composer.json 改了 require，却忘了 git add composer.lock。只要 composer.lock 没提交，别人拉下来就永远装不到你本地测试过的那套依赖。
