composer update 会完整重写 composer.lock 文件，基于 composer.json 中的版本约束重新计算整个依赖图并锁定精确版本；不带参数时更新所有包，指定包名则只更新该包及其可变子依赖，--lock 参数仅同步锁文件格式而不升级包。
直接运行 composer update 会更新 composer.lock
只要项目中已有 composer.json，执行 composer update 就会重新解析依赖、下载最新匹配版本，并完整重写 composer.lock 文件。这不是“刷新”或“同步”，而是基于当前 composer.json 中的约束（如 "monolog/monolog": "^2.0"）重新计算整个依赖图并锁定精确版本。
常见错误现象：
– 手动改了 composer.json 但没运行 composer update，composer.lock 仍是旧状态；
– 运行了 composer install，结果提示 “Lock file is not up to date”，因为 install 只按锁文件装，不更新锁文件。
-
composer update不带参数：更新所有包（含子依赖），最彻底，但也最可能引入不兼容变更 -
composer update vendor/package：只更新指定包及其可变子依赖，更可控 - 加
--dry-run参数先看会更新哪些包，避免误操作 - 加
--with-dependencies可确保指定包的直系依赖也被纳入更新范围（默认不一定）
想保留现有版本只同步锁文件？用 composer update --lock
这个命令不会下载或升级任何包，只根据当前 composer.json 和已安装的 vendor 内容，重新生成一份语义等价、格式合规的 composer.lock。适用于以下场景：
- 多人协作中
composer.lock格式不一致（比如换行符、字段顺序），想统一格式 - 删掉了
vendor/但没删composer.lock，又不想重装全部依赖，只想让锁文件和composer.json对齐 - CI 环境中需确保锁文件结构规范，避免因格式差异触发误提交
注意：--lock 不校验已安装包是否真满足 composer.json 约束——它假设 vendor 是对的。如果实际装的版本已偏离约束（比如手动改过 vendor），这个命令不会报错，但可能导致后续 install 行为异常。
composer install 什么时候会改 composer.lock？
正常情况下，composer install 绝对不会修改 composer.lock —— 它只读取锁文件并按里面记录的版本安装。但有两个例外：
- 项目根目录下根本没有
composer.lock文件，此时install会退化为自动执行一次update并生成锁文件（等价于composer update --no-install+ 写锁） - 运行时加了
--no-lock参数，强制跳过锁文件，行为同update
所以如果你发现 install 后锁文件变了，第一反应应该是检查是否存在上述两种情况，而不是怀疑命令本身有副作用。
更新锁文件后要注意什么？
composer.lock 是生产环境行为的唯一依据，它的变更必须被 Git 跟踪。漏提交锁文件是线上部署出问题的高频原因。
- 每次
composer update或composer update --lock后，务必git add composer.lock && git commit -m "update composer.lock" - 若团队使用不同 Composer 版本（如 2.2 vs 2.5），锁文件中
content-hash和部分字段顺序可能不同，建议统一 Composer 版本（通过composer self-update或phive锁定） - PHP 版本变化会影响依赖解析结果（例如某些包在 PHP 8.2 下不再提供 v7 兼容版），更新锁文件前确认
config.platform.php设置与目标环境一致
锁文件不是中间产物，它是契约。生成它很容易，但理解它为何变、为何不能跳过、为何要和 composer.json 协同演进，才是关键。
