Composer PHP依赖锁定机制_Composer使用lock文件技巧【规范】-composer-PHP中文网

composer锁定依赖需同时满足：composer.json写三位完整版本号（如"monolog/monolog": "2.9.1"）、composer.lock提交至git、部署时运行composer install；缺一不可，否则仍会升级版本。

composer php依赖锁定机制_composer使用lock文件技巧【规范】

Composer 锁定依赖不是靠命令开关或配置项，而是靠 composer.json 写死版本 + composer.lock 提交到 Git + 部署时执行 composer install —— 三者缺一不可。少一个，就等于没锁。

关键在 composer.json 的 require 或 require-dev 字段里怎么写版本号：

✅ 正确："monolog/monolog": "2.9.1" —— 纯数字、三位完整、不含任何符号（^、~、*、甚至省略补丁号的 "2.9" 都不行）
❌ 错误："monolog/monolog": "^2.9"、"~2.9.0"、"2.9.*"、"2.9" —— 这些都允许 Composer 在语义化范围内自动升级
⚠️ 改完后必须立刻运行 composer update monolog/monolog，否则 composer.lock 不会更新，等于白改
验证是否生效：运行 composer show monolog/monolog，输出版本必须是 2.9.1；再跑一次 composer update monolog/monolog，若提示 Nothing to install or update，才算锁成功

composer.lock 不是缓存，是整个依赖树的“快照”：它记录每个包的确切版本、源码 commit hash、dist URL、校验和、甚至嵌套依赖路径。没有它：

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

composer install 会退化为按 composer.json 重新解析依赖，哪怕你写了 "2.9.1"，也可能装上 2.9.2（尤其镜像源缓存了新版本）
CI 构建、新同事拉代码、Docker 构建，都会拿到不一致的依赖，典型现象是本地能跑、线上报 Class not found
删掉 composer.lock 后执行 composer install，等价于执行了一次 composer update，所有包都会漂移
CI/CD 脚本里用了 composer install --no-lock 或 composer update，直接绕过锁定逻辑

生产环境唯一可信流程是：composer install，且前提是 composer.lock 已提交、未被修改、未被忽略：

上线前加一道保险：composer install --locked —— 它会校验 composer.lock 中每个版本是否仍满足 composer.json 的约束，不满足直接报错退出，不让你稀里糊涂上线
CI 脚本里禁用 composer update，哪怕只是“顺手更新一下”，也必须用 composer install --no-dev --no-interaction
如果 composer show -s 输出 Lock file is not up to date，说明 composer.json 和 composer.lock 对不上；此时该跑 composer install（保持现状）还是 composer update（接受变更），取决于你是否主动改了 composer.json

看似无害的操作，可能让锁定失效或引入不一致：

手动修改 composer.json 后只运行 composer install —— 这不会更新 composer.lock，新依赖或版本变更根本不会生效
把 composer.lock 加入 .gitignore —— 它必须被提交到 Git，否则协作和部署就失去锁定意义
用 composer require xxx --no-update 添加包后忘记运行 composer update —— 新包不会出现在 composer.lock 中
在不同 PHP 版本或平台（Linux/macOS/Windows）上运行 composer update，可能导致 composer.lock 中的 platform 字段或扩展依赖不一致
CI 脚本里误用 composer update 而非 composer install，导致每次构建都产生新 composer.lock，破坏可重现性