vendor目录必须进.gitignore，因其是Composer根据composer.json和composer.lock自动生成的可重建产物；提交会导致第三方代码重复、环境差异冲突、仓库膨胀及无效diff；标准写法为vendor/，需配合git rm -r --cached vendor清除缓存，并必须提交composer.lock以保障依赖一致性。
vendor 目录为什么必须进 .gitignore
因为 vendor 是 Composer 安装依赖时自动生成的，内容完全由 composer.lock 和 composer.json 决定；直接提交会导致：重复提交第三方代码、不同环境生成路径/符号链接不一致、Git 历史膨胀、PR 中出现大量无意义 diff。
标准 .gitignore 条目怎么写才不漏不滥
只需一行就足够，且必须放在 .gitignore 文件顶部附近（避免被后续规则覆盖）：
vendor/
注意以下常见错误：
- 写成
vendor（缺末尾斜杠）→ 会误忽略同名文件或目录vendor.php或myvendor - 写成
/vendor/（加前导斜杠）→ 只忽略项目根目录下的vendor/，若子目录里也有叫vendor的（极少见但可能），会被漏掉 - 写成
**/vendor/→ 多余，vendor/默认递归匹配所有层级
要不要忽略 composer.lock？
要提交，且必须提交。
Git Changelog Generator
下载
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
-
composer.lock锁定了所有依赖的确切版本和哈希值，是保证composer install在各环境产出一致vendor/的唯一依据 - 不提交
composer.lock，CI 构建或同事拉代码后执行composer install会安装最新兼容版本，极易引发运行时差异甚至报错 - 只有当你明确想升级依赖并重新生成锁文件时，才修改它——此时应连同
composer.json一起提交
本地开发时误提交了 vendor/ 怎么撤回
如果刚提交还没推，用这条命令清空暂存区并保留本地文件：
git rm -r --cached vendor/
然后提交 .gitignore 更新和这次清理：
git add .gitignore<br>git commit -m "chore: ignore vendor directory"
如果已推送到远程，需额外处理：
- 执行
git rm -r --cached vendor/+ 提交 - 通知协作者执行
git pull后运行composer install（不是update） - 历史中已存在的
vendor/不会自动删除，但新克隆仓库将不再包含它
真正麻烦的是 vendor/ 里混入了你手写的私有包或 patch 文件——这类情况不属于标准流程，得靠人工核对和迁移，.gitignore 帮不上忙。
