必须用 composer install 恢复依赖，因为它严格按 composer.lock 记录的版本、哈希和嵌套依赖安装，确保环境一致性；composer update 会忽略 lock 文件重解析依赖，导致版本漂移和线上风险。
直接用 composer install 恢复依赖，别碰 composer update——这是同步失效时最稳、最安全的操作。所有“不同步”现象，本质都是本地 vendor 与 composer.lock 不匹配，或 composer.lock 与远程分支不一致。
为什么 composer install 是首选操作
它严格按 composer.lock 中记录的版本、哈希、嵌套依赖关系安装，不重新解析、不跳过、不猜测。只要 composer.lock 文件本身是最新且有效的，composer install 就能还原出和 CI/生产环境完全一致的 vendor 目录。
- 运行前先确认：当前 PHP 版本、已启用扩展（如
ext-intl）满足composer.lock中platform字段要求 - 如果报错
Root composer.json requires xxx, but it is not satisfied，说明composer.json和composer.lock已脱节，需先合并或重生成composer.lock - Windows 下若提示
file could not be downloaded: failed to open stream，大概率是 OpenSSL 证书路径失效，临时加--no-secure-http可绕过（仅限本地调试）
Git 合并时 composer.lock 冲突怎么处理
手动编辑冲突标记是高危操作，composer.lock 是 JSON 快照，不是配置文件。Git 报冲突，通常只是两个分支各自执行过 composer update 或增删了包，导致哈希与依赖树不一致。
- 先检查
composer.json是否也冲突——必须先解决composer.json的差异，否则后续无从谈起 - 不要用
git checkout --ours/--theirs强行保留某一方的composer.lock，这会破坏依赖完整性 - 稳妥做法：暂存当前
composer.lock→ 切到主干分支 →composer install→ 切回功能分支 → 手动执行composer require xxx或composer remove xxx恢复本分支变更 → 运行composer update --lock（只刷新哈希，不改依赖）→ 提交新composer.lock - CI/CD 中频繁失败？在项目根目录加
.gitattributes，写入composer.lock merge=ours，让 Git 自动采用当前分支版本（适合主干优先策略）
composer.lock 明明提交了，但别人 install 还是失败
常见于跨平台或环境升级后，比如你本地 PHP 8.2 生成的 lock 文件，被同事在 PHP 8.1 上执行 composer install，而 lock 里锁的某个包已要求 php >= 8.2。
- 检查
composer.lock顶部的platform字段，对比当前运行环境：php -v、php -m | grep intl - 若环境确实不满足，不要加
--ignore-platform-reqs硬上——这会让 lock 失去约束意义，应统一开发环境或调整config.platform - 团队应统一配置镜像源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，避免因源不同导致元数据解析差异 - 离线部署时，只传
composer.lock不够，必须打包完整vendor目录（或使用composer archive），否则生产机可能因网络/源问题拉不到对应版本
真正容易被忽略的是：lock 文件没有“长期有效性”。它只承诺“当时能装”，不保证“永远可用”——Packagist 下架包、PHP 版本淘汰、扩展废弃，都会让一个曾经有效的 lock 文件突然失效。所以每次重大环境变更后，都该重新审视并必要时重建 lock。
