vendor目录不是源码而是可重建的依赖快照，不应提交至Git；需在.gitignore中排除vendor/、vendor/bin/、composer.phar等；仅离线构建或老旧PHP项目等极少数场景可局部保留。
vendor 目录不是项目源码，而是依赖快照
Composer 的 vendor 是根据 composer.json 和 composer.lock 动态生成的安装结果，本质是「可重建的产物」，不是你写的代码。把它提交进 Git，相当于把 node_modules 或 target/ 打包进仓库——它体积大、变更频繁、含平台相关文件（比如扩展的 .so/.dll），且每次 composer install 都可能因环境差异产生微小不一致。
重复提交 vendor 会破坏 lock 文件的语义
composer.lock 的核心作用是锁定**确切版本+哈希校验值**，确保所有环境装出完全一致的依赖树。一旦 vendor 被提交，团队成员可能跳过 composer install 直接用旧文件，或手动改了某包又没更新 lock，导致：
-
composer update后vendor和lock不同步 - CI 构建时用
install命令却加载了被污染的本地vendor - Git diff 里出现大量无关的二进制/自动生成文件（如
autoload_classmap.php）
.gitignore 里只写 vendor 不够，还要排除生成文件
除了根目录下的 vendor/，以下内容也必须加入 .gitignore：
-
composer.phar（不应提交可执行工具） -
vendor/bin/*（符号链接或包装脚本，不同系统行为不一） -
vendor/*/composer/installers等插件生成的临时结构（部分旧版 installer 会写入 vendor 内部） - 如果用了
composer config bin-dir自定义路径，对应目录也要忽略
vendor/ composer.phar vendor/bin/ !vendor/bin/*
例外情况：只有极少数场景需要暂存 vendor
绝大多数项目不需要，但以下两类可考虑局部保留（仍不推荐提交到主分支）：
- 离线构建环境：CI runner 完全无外网，且无法挂载缓存，此时可将
vendor打包为 artifact，但应通过 CI 系统分发，而非 Git 提交 - 遗留 PHP 5.3 项目使用老旧 Composer 版本（lock 校验机制不完整，被迫靠
vendor保一致性——这说明该升级 Composer 或 PHP，而不是妥协于 Git
composer.lock 始终被提交、且每次依赖变更后都由 composer update + 提交 lock 双步骤完成。很多人删了 .gitignore 里的 vendor 行，以为“看得见才安心”，其实反而埋下了协作和部署的隐性故障点。 
