生产环境绝不能没有composer.lock，因为composer.install依赖它精确还原依赖；缺失时会报错或退化为update导致版本漂移。
生产环境根本不能靠 composer install 从头生成 composer.lock —— 它压根不存在时，composer install 会直接报错或退化为 composer update，导致版本漂移、不可控依赖上线。
为什么生产环境绝不能没有 composer.lock
composer.lock 是部署确定性的唯一依据。它记录了每个包的精确版本、哈希值、嵌套依赖路径和安装顺序。没有它，composer install 就失去“还原”能力，只能重新解析 composer.json，而这个过程受 PHP 版本、平台扩展、Composer 版本、网络元数据缓存等多重影响，结果不可复现。
- CI 构建失败常见于 Git 仓库未提交
composer.lock（被误加进.gitignore） - 手动在服务器上运行
composer install报Command "install" is not defined（Composer v2.5+），本质就是 lock 缺失触发的保护机制 - 有人删了 lock 后硬跑
composer install --no-dev，结果装出一堆不兼容的 dev-only 包（比如phpunit/phpunit的传递依赖），因为没 lock 就没过滤依据
正确补救流程：先回溯，再重建，最后验证
别在生产机上瞎试。所有操作必须在与生产环境一致的干净开发/CI 环境中完成：
- 确认目标环境 PHP 版本（如
php -v输出8.1.22），并检查composer.json中"config": {"platform": {"php": "8.1.22"}}是否存在且匹配；不匹配就删掉或修正 - 执行
composer check-platform-reqs，确保ext-dom、ext-mbstring等关键扩展已启用，否则后续update会卡死 - 运行
composer update --no-dev --lock（Composer v2.2+）：它只重写composer.lock，不碰vendor/，生成的 lock 文件完全对应当前已安装状态，安全可控 - 若
vendor/也缺失或混乱，用composer update --no-dev --prefer-dist --optimize-autoloader全量重建，再提交新composer.lock
CI/CD 流水线里必须堵死这个漏洞
一旦漏掉 composer.lock，整个部署链就失去可信基础。以下三点是硬性守则：
- Git 提交前强制检查：
git status --porcelain | grep '?? composer.lock'，有输出即阻断 PR - CI 脚本开头加校验：
test -f composer.lock || (echo "ERROR: composer.lock missing"; exit 1) - Docker 构建阶段禁止
RUN composer install单独出现，必须前置COPY composer.lock .，且composer.lock必须在composer.json之后 COPY，否则缓存失效
最常被忽略的一点：composer.lock 不是“一次生成永久有效”。它只对生成时的 PHP 和扩展版本负责。如果你升级了 PHP 小版本（比如从 8.1.10 到 8.1.22），即使没改 composer.json，也该重新运行 composer update --lock 并提交 —— 否则旧 lock 可能锁住已废弃的兼容版本，导致 install 失败。
