composer install 严格按 composer.lock 还原依赖，不查 composer.json 版本范围；composer.update 重写 lock 文件并升级依赖。lock 文件必须提交 git，确保环境一致。
为什么 composer install 不装新包，而 composer update 会改版本？
因为 composer.lock 是精确依赖快照——它记录了每个包的完整版本号、commit hash（对 dev 分支）、安装时的 PHP 扩展要求等。只要 lock 文件存在，composer install 就严格按它还原，不查 composer.json 的版本范围。
常见错误现象：composer install 后发现本地包版本和同事不一致，或 CI 构建失败，大概率是有人漏提交 composer.lock，或者自己手动删过它又没重新生成。
- 团队协作中，
composer.lock必须进 Git，且不能忽略 -
composer update只应在明确要升级依赖时运行，它会重写composer.lock，并可能引入兼容性问题 - CI/CD 环境必须用
composer install --no-dev（如果不需要测试依赖），否则可能因开发依赖缺失报错
如何确保本地和同事的 vendor 完全一致？
关键不是“装得快”，而是“装得准”。速度只是结果，前提是 lock 文件干净、PHP 环境匹配、网络源稳定。
使用场景：拉完同事代码后，首次运行 composer install；或清理 vendor 重装时。
- 先确认
git status中composer.lock已更新，且无未提交修改 - 检查 PHP 版本是否满足 lock 文件里记录的最低要求（看
composer.lock顶部的platform字段） - 国内用户建议配置阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 加
--prefer-dist（默认开启）可跳过 git clone，直接下 zip 包，更快更稳
composer install 报错 “Your requirements could not be resolved” 怎么办？
这不是网络问题，是 lock 文件和当前环境冲突了。典型原因：PHP 版本降级、扩展被禁用（如 ext-zip）、或 lock 文件里记录了已废弃的包源。
错误信息示例：Your lock file does not contain a compatible set of packages. Please run composer update.
- 别急着
update—— 先看报错里具体哪个包不兼容，再查composer.lock对应条目里的php或ext-xxx约束 - 用
php -m确认必需扩展已启用；用php -v核对小版本（如 8.1.23 vs lock 里写的 >=8.1.0） - 若确认环境无误，可能是 lock 文件损坏，可尝试
composer install --ignore-platform-reqs临时绕过检查（仅调试用，勿提交）
CI 构建时要不要删掉 vendor 再 install？
要，但方式很重要。CI 每次都该从干净状态开始，否则缓存污染会导致行为不可预测。
性能影响：重复下载包确实慢，所以几乎所有 CI 都会缓存 ~/.composer/cache 目录，而不是缓存整个 vendor。
- 推荐流程：清空
vendor→ 运行composer install --no-interaction --no-progress --optimize-autoloader -
--optimize-autoloader会生成静态类映射，提升加载速度，尤其在无 OPcache 的 CI 环境里明显 - 不要用
composer update替代install，CI 不该决定依赖版本
最易被忽略的一点：lock 文件里记录的包哈希值，是基于压缩包内容计算的。如果某包发布后被作者悄悄重推（tag 不变但 zip 内容变了），Composer 会校验失败并拒绝安装——这时只能联系包维护者，或临时用 --ignore-platform-reqs 强制过，但务必同步反馈问题。
