应删 composer.lock 后运行 composer install 重解依赖，或执行 composer update --lock 仅更新锁文件结构；不可忽略该错误，否则会导致环境不一致或类加载异常。
composer install 报 “Your lock file does not contain a compatible set of packages” 怎么办
这是 composer install 运行时最典型的保护性中止，不是 bug，是它在明确告诉你：composer.json 和 composer.lock 已经对不上了——不能装，也不敢装。
常见触发场景包括：别人提交了改过 composer.json 的代码（比如增删包、调版本），但没同步提交新 composer.lock；你本地手动改过 composer.json 后忘了跑 composer update；Git 合并时没处理好 composer.lock 冲突，残留了
- 别删
composer.lock重来——这会让所有依赖重新解析，可能引入未测过的版本组合 - 也别硬加
--ignore-platform-reqs或--no-lock绕过——它们不解决根本不一致，只掩盖问题 - 先确认当前
composer.json是你真要的版本（比如刚 pull 了同事的 PR），再决定用哪边的 lock
git merge 后 composer.lock 出现冲突标记，怎么安全清理
手动删冲突行、调整缩进、凑合保留某一方内容，都会破坏 composer.lock 的 content-hash 校验。后续 composer install 要么失败，要么加载错类。
正确做法分三步：
- 用
git checkout --ours composer.lock或git checkout --theirs composer.lock任选其一，还原成干净的、无冲突标记的文件（推荐选目标分支，如main） - 删掉整个
vendor/目录，避免旧包残留干扰 - 运行
composer install—— 如果还原后的composer.lock和当前composer.json不匹配，它会立刻报错，逼你停下来确认要不要重新生成 lock
想让 lock 文件适配当前 composer.json，但不想升级任何包
你只是改了 autoload、scripts 或 description 字段，composer.json 变了但依赖树没变。此时不需要重算整棵树，只需刷新 lock 文件的哈希和元数据。
运行：
composer update --lock
这个命令不做任何安装、卸载或版本变更，只重写 composer.lock，保持所有包版本完全不变，仅更新 content-hash、packages 列表顺序和时间戳。
注意：composer update --lock 不接受包名参数，也不能加 --with-dependencies——它只作用于 lock 文件本身。
CI 流水线里 composer install 失败，但本地能跑
大概率是平台环境差异：CI 节点的 PHP 版本、已启用扩展、甚至 OpenSSL 配置，和你本地不一致。而 composer.lock 里记录了 "platform" 字段（比如 "php": "8.1.0"），install 时会严格校验。
排查顺序：
- 检查 CI 日志里是否出现
The requested PHP extension xxx is missing—— 缺扩展就装，别跳过 - 运行
composer install --dry-run --no-dev，看退出码；非 0 就说明 lock 文件和当前平台不兼容 - 确认 CI 使用的 PHP 版本是否和
composer.lock中platform.php声明一致（不是看composer.json的config.platform.php） - 不要在 CI 脚本里加
--ignore-platform-reqs—— 它绕过的是 lock 文件里存的约束，等于主动放弃可重现性
真正容易被忽略的是：lock 文件不是“一次生成永久有效”的快照，它是带平台上下文的。PHP 升级、扩展增减、甚至某些系统库更新，都可能让它失效。
