为什么 vendor 目录不该提交到 Git
因为 vendor 是 Composer 根据 composer.json 和 composer.lock 自动还原出来的，不是你写的代码。提交它会导致仓库臃肿、diff 失控、协作冲突频发，还可能混入本地调试时临时安装的 dev-only 包。
Git 里只留 composer.json 和 composer.lock 就够了——别人克隆后运行 composer install 就能拿到完全一致的依赖树。
.gitignore 里加 vendor 的正确写法
直接在项目根目录的 .gitignore 文件末尾加一行就行，但要注意路径和斜杠细节：
/vendor —— 推荐。开头的 / 表示只忽略项目根下的 vendor 目录，避免误伤子目录里同名的 vendor别写成 vendor/ 或 vendor（没斜杠也没前缀），前者在某些旧 Git 版本中行为不稳，后者会匹配所有含 vendor 字样的路径（比如 myvendor.php）如果之前已经提交过 vendor，光改 .gitignore 没用，得先让 Git “忘记”它：git rm -r –cached vendor，再 git commit
composer install 和 composer update 的区别影响 Git 状态
这两个命令对 composer.lock 的处理方式，直接决定你是否该提交这次变更：
composer install —— 只读 composer.lock，装里面锁定的版本。不改任何文件，不用提交composer update —— 升级依赖、更新 composer.lock。只要 composer.lock 变了，就必须 git add composer.lock && git commit漏提交 composer.lock 是最常见协作问题：别人 composer install 装出来的包版本跟你本地不一致，环境就“看似一样实则不同”
CI/CD 或部署脚本里别跳过 lock 文件校验
很多自动化流程图省事，直接 composer install –no-interaction，但前提是 composer.lock 必须存在且已提交。否则 Composer 会退化成 composer update 行为，装最新兼容版——这跟本地开发环境就不一致了。
检查点很实在：
CI 脚本开头加一句：test -f composer.lock || { echo "composer.lock missing"; exit 1; }部署机上如果 composer install 报错 “Your lock file does not contain a compatible set of packages”，说明 composer.json 和 composer.lock 已脱节，得先本地 composer update 并提交新 lock
vendor 目录本身是临时产物，但 composer.lock 是契约。契约松动，比没写 .gitignore 更难排查。
评论(0)