composer update --lock 仅根据 composer.json 重写 lock 文件而不更新依赖；真正更新某包需用 composer update ，手动修改 lock 不推荐且易致校验失败。
composer update --lock 不会更新依赖，只重写 lock 文件
很多人以为 composer update --lock 是“强制更新某条 lock 记录”，其实它只是根据当前 composer.json 重新生成 composer.lock，不触碰任何包的下载或版本变更。它不会升级、降级、重装任何包，也不会解决冲突——只是把 lock 文件“格式化”成当前 json 所声明的依赖快照（前提是没改动过依赖声明）。
如果你改过 composer.json 里的某个包版本（比如把 "monolog/monolog": "^2.0" 改成 "^3.0"），再运行 composer update --lock，它才可能让 lock 中对应项变更为新约束下的解析结果；但若 json 没变，lock 内容也几乎不变（仅可能更新哈希或平台信息）。
想强制更新某个包并同步 lock，必须用 composer update
真正能改变 lock 中某项的，是 composer update 加上具体包名。它会重新解析该包及其子依赖，更新到符合当前 composer.json 约束的最新可用版本，并刷新 composer.lock。
- 只更新一个包：
composer update monolog/monolog
- 同时更新多个包：
composer update monolog/monolog symfony/console
- 加上
--with-dependencies可连带更新其直接依赖（谨慎使用，易引发连锁升级） - 加
-v查看详细解析过程，确认到底哪些包被实际更新了
注意：如果该包在 composer.json 中未显式声明（比如是其他包的子依赖），直接 composer update vendor/package 会报错 Package "vendor/package" listed for update is not required in your composer.json。此时需先在 json 中添加，或改用 composer update --with-all-dependencies（风险更高）。
绕过 composer.json 强制指定 lock 中某条版本？不推荐但有临时方案
Composer 官方不支持“只改 lock 不改 json”的操作，因为这会破坏一致性校验（install 时会报错 The lock file does not contain require-dev information 类提示，或更严重的 hash mismatch）。但极少数调试场景下，有人手动编辑 composer.lock：
- 找到对应包的
name和version字段，改成目标版本（如"version": "3.5.0"） - 同步修改该包的
dist下shasum（必须和真实 zip 包一致，否则 install 失败） - 删掉整个
vendor/目录，再跑composer install—— 它会按 lock 拉取，但很可能因版本不匹配依赖而失败
这不是正向流程，composer install 会校验 composer.json 和 composer.lock 的依赖树是否兼容。手动改 lock 后 install 报错是常态，不是 bug。
常见误操作与排查线索
执行完命令发现 lock 文件没变？检查这些：
-
git status看composer.json是否真有变更（比如你改了注释但没改依赖） - 运行
composer show monolog/monolog确认当前已安装版本 - 对比
composer.json中该包的约束（如^2.8）和你想升到的版本（如3.5.0）是否兼容——如果不兼容，update 不会动它 - 留意输出里有没有
Nothing to install or update，这是最常被忽略的提示 - 私有仓库或
minimum-stability设置可能导致期望版本不可见，加-vvv看完整 resolver 日志
lock 文件本质是确定性快照，它的“强制更新”只能通过改变输入（json）或触发解析（update 命令）来实现。没有捷径，也没有隐藏开关。
