根本原因是composer.lock未被正确维护，它可能未提交、被忽略或未更新，导致不同机器按不同约束安装依赖，进而引发版本不一致。
composer install 为什么在不同机器上装出不一样的 vendor？
根本原因不是 composer install 本身有问题，而是它默认只读 composer.lock —— 但这个文件可能没提交、被忽略、或没更新。
- 团队里有人改了
composer.json但忘了运行composer update再提交composer.lock，别人install就会按旧 lock 装，或者干脆 fallback 到 json 的模糊版本约束（比如"^8.0"），结果装到 8.2 或 8.3 都可能 -
.gitignore里误加了/vendor是对的，但顺手把composer.lock也 ignore 了 —— 这个文件必须进 Git - PHP 版本不一致时，某些包会在
composer.lock里记录不同平台的 dist hash，但若 lock 文件生成时没开--lock或用了composer update --no-lock，就会漏掉平台一致性保障
多人协作时 composer.lock 文件怎么维护才不出错？
它不是“生成一次就不管”的快照，而是需要主动同步的依赖契约。关键在谁改、怎么改、何时提交。
- 只有一个人有权限执行
composer update（比如 Tech Lead），其他人一律只用composer install - 新增/删包必须走 PR：先改
composer.json→ 本地composer update xxx（精确到包）→ 检查生成的composer.lock变更是否只含该包及其依赖 → 提交这两个文件 - CI 流水线里加一步校验：
composer install --dry-run，如果报 “lock file is not up to date with composer.json” 就直接失败，防人绕过流程
vendor 目录同步慢 / 占空间大，能跳过重装吗？
不能靠复制 vendor 目录来“同步”，因为里面含绝对路径的 autoloader、平台相关二进制（如 phpunit）、以及 symlink 行为在不同系统上表现不一。真要提速，得换策略。
- 用
composer install --prefer-dist（默认行为），优先下 zip 包而非 git clone，比--prefer-source快得多 - 启用 Composer 全局缓存：
composer config -g cache-dir ~/.composer/cache，同一台机器多次 install 会复用已下载的 dist 包 - Docker 场景下，在
Dockerfile中把composer.lock和composer.json单独 COPY 并提前 runcomposer install，利用 layer 缓存，避免每次重装
CI/CD 里 vendor 安装失败常见报错和对应动作
错误往往不是网络问题，而是环境或配置偏差。看到报错先盯住这几行：
-
Package x/y has a PHP requirement incompatible with your PHP version→ 检查 CI 镜像 PHP 版本是否和本地一致，别用php:latest，固定写成php:8.1-cli -
Failed to clone https://github.com/xxx, git was not found→--prefer-dist没生效，CI 镜像里没装 git；要么装 git，要么强制加--prefer-dist -
Class XXX not found即使 vendor 看起来装好了 → autoloader 没重建，补一句composer dump-autoload --optimize，尤其在 Docker 多阶段构建中容易漏掉
lock 文件的哈希值是 per-platform 的，Windows 和 Linux 下生成的 lock 不完全兼容；如果团队混用系统，建议统一在 CI 环境生成 lock 文件再提交 —— 别信本地 commit 的那个。
