应运行 composer update --lock 补全 require-dev 字段，不改变依赖版本；若本地有修改且不提交新 lock，可加 --no-scripts 避免触发脚本。
composer install 报错“Your lock file does not contain require-dev information”
这是最常见的锁死表现：不是真被锁，而是 composer.lock 和 composer.json 不匹配，尤其是 dev 依赖缺失。Composer 拒绝降级或跳过校验，直接报错退出。
- 别急着删
composer.lock—— 如果项目在 CI 或多人协作中，删了会导致依赖版本漂移 - 先运行
composer update --lock，它只更新 lock 文件结构（补全 require-dev 字段），不改依赖版本 - 如果本地有修改但不想提交新 lock，加
--no-scripts避免触发 post-update-cmd - 某些旧版 Composer（--lock，得升级：
composer self-update
删了 composer.lock 后 composer install 装出来的包和以前不一样
删 lock 文件本身合法，但后果是「重算整个依赖图」—— Composer 会按 composer.json 中的版本约束（如 "^2.4"）拉最新兼容版，不是原来那个。
- 想复现旧环境？必须保留原
composer.lock，或从 Git 历史里 checkout 出来 - 如果 lock 已丢失且没备份，用
composer show --tree查当前装了哪些包+版本，再手动写进composer.json的精确版本（如"monolog/monolog": "2.9.1"），再删 lock 重装 -
composer install只认 lock；composer update才走 json 约束 —— 这个区别常被忽略
CI 流水线里删 lock 文件导致构建失败
很多 CI 脚本粗暴执行 rm composer.lock && composer install，结果在不同机器上装出不同依赖，某天突然挂掉。
- CI 应该做的是：确保
composer.lock提交进 Git，并在构建前校验它是否和composer.json一致（composer validate --strict） - 若需强制刷新 lock（比如升级 PHP 版本后），用
composer update --lock --ignore-platform-reqs，而不是删 - GitLab CI / GitHub Actions 中，缓存
vendor/时务必同时缓存composer.lock，否则缓存失效逻辑会出错
composer.lock 是手段，不是目的；真正要解决的，是 lock 和 json 的同步关系。很多人删了又重装，却没检查 composer.json 里是不是混进了本地调试用的 require-dev，或者用了已被弃用的平台配置。 
