/vendor必须加开头斜杠以精确匹配根目录下的vendor目录，避免误匹配如myvendor.php等文件；改.gitignore后须执行git rm -r --cached vendor清除缓存，否则仍会追踪；vendor/bin/和composer.phar也需一并忽略；composer.lock是依赖一致性契约，必须提交且与composer.json严格对齐。
为什么/vendor必须带开头斜杠
不加/会匹配任意路径中含vendor字符串的文件，比如myvendor.php、vendorize甚至src/vendor_api/——这些都不是你要忽略的目标。/vendor明确限定只忽略项目根目录下的vendor目录，Git 所有版本都稳定识别，无歧义。
git rm -r --cached vendor这步不能跳过
改完.gitignore后，Git 不会自动停止追踪已提交过的vendor/。常见错误现象是：新人克隆仓库后git status仍显示一堆vendor/修改未暂存，就是因为缓存没清。
- 执行
git rm -r --cached vendor：从索引中移除，但保留本地文件（不影响当前开发） - 执行
git commit -m "remove vendor from git tracking"：提交清理动作 - 验证是否干净：
git ls-files | grep "^vendor/"应无输出
别漏掉vendor/bin/和composer.phar
vendor/bin/里全是符号链接或包装脚本，不同系统生成行为不一致；composer.phar是可执行工具，不是项目源码。它们和/vendor一样，属于可再生产物，必须一并排除。
- 在
.gitignore中追加两行：vendor/bin/和composer.phar - 如果自定义了
bin-dir（如"config": {"bin-dir": "tools/bin"}），对应路径也要加进.gitignore - 不用写
!vendor/bin/autoload.php这类反向规则——整个vendor/已被忽略，内部文件天然不受影响
composer.lock才是真正的契约，比.gitignore更重要
很多人花时间调.gitignore，却漏提交composer.lock。结果别人composer install装出来的包版本跟你不一致，问题藏得深、难复现。
-
composer.lock必须提交，且每次composer update后要立刻git add composer.lock && git commit - CI 脚本开头建议加校验：
test -f composer.lock || { echo "composer.lock missing"; exit 1; } - 部署机上若报
Your lock file does not contain a compatible set of packages，说明composer.json和composer.lock已脱节，不是.gitignore的问题，而是本地没跑composer update再提交
composer.lock没对齐，vendor 目录哪怕完全没进 Git，环境也照样不一致。
