应删掉本地 composer.lock 后运行 composer install；若仅微调依赖，可用 composer update --lock；切勿手动编辑 composer.lock。
composer install 报错 “Your lock file does not contain a compatible set of packages” 怎么办
这是最典型的锁定冲突现象：你改了 composer.json，但没更新 composer.lock，或者多人协作时本地 composer.lock 和远程不一致。Composer 拒绝妥协，直接报错停住。
核心原则：不要手动编辑 composer.lock —— 它是自动生成的快照，不是配置文件。
- 先确认改动来源：是自己加了新包？删了依赖？还是升级了 PHP 版本导致平台约束变化？
- 如果只是新增/删减少量包，运行
composer update --lock（仅更新 lock 文件，不重装包） - 如果本地
composer.json和团队主干一致，但composer.lock不同，直接删掉本地composer.lock，再跑composer install - Git 合并冲突时出现 composer.lock 里？别修它 —— 放弃当前 lock，用
git checkout origin/main -- composer.lock拉最新版，再composer install
composer update 和 composer install 到底该用哪个
二者行为完全不同，混用是冲突高发原因。
-
composer install：只读composer.lock，严格安装里面记录的版本和哈希。适合部署、CI、团队协同 —— 确保所有人装的一模一样 -
composer update：忽略composer.lock，按composer.json重新解析依赖树，生成新 lock。适合开发阶段引入新功能或升级依赖 - CI 脚本里写
composer update？大概率导致构建结果漂移。应该用composer install，且确保composer.lock已提交到 Git - 想升级某一个包（比如
monolog/monolog），用composer update monolog/monolog，而不是全量 update —— 减少意外连带升级
PHP 版本变更后 composer.lock 不兼容怎么办
PHP 8.2 升级到 8.3 后，composer install 报 “platform check failed” 或提示某些包不满足 php 约束，本质是 lock 文件里记录的包版本已不适用于当前环境。
- 先检查
composer.json里的"platform": {"php": "8.3"}是否已更新（如有 platform 配置） - 运行
composer update --ignore-platform-req=php强制跳过 PHP 版本检查（临时调试用，不推荐长期） - 更稳妥做法：删掉
composer.lock，再跑composer install—— Composer 会基于当前 PHP 版本 +composer.json重新生成兼容的 lock - 注意：有些包在 PHP 8.3 下已废弃扩展（如
ext-mcrypt），对应依赖可能彻底无法安装，得查文档换替代方案
多人协作中如何避免 composer.lock 冲突
lock 文件天生易冲突，因为它是 JSON 格式、字段顺序敏感、还含哈希值 —— Git 默认 diff 看起来全是红的，但实际可能只差一行。
- 所有成员必须统一使用相同 major 版本的 Composer（比如都用 Composer 2.5.x，别有人用 1.x）
- 提交前运行
composer update --dry-run看是否有隐性变动；有就 commit 新 lock - 禁止把
composer.lock加进.gitignore—— 它必须进 Git，否则失去“可重现安装”的意义 - 合并分支前，先
git pull origin main，再composer install确认无报错，再提交自己的改动
lock 文件不是黑盒，但它也不该被当作文本文件去 merge。关键在于理解它和 composer.json 的契约关系：后者是声明，前者是承诺。一旦承诺失效，就得重新签一份，而不是拿笔涂改。
