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

真正关键的不是“忽略 vendor”，而是确保 composer.lock 始终被提交、且每次依赖变更后都由 composer update + 提交 lock 双步骤完成。很多人删了 .gitignore 里的 vendor 行，以为“看得见才安心”，其实反而埋下了协作和部署的隐性故障点。