应避免随意运行 composer update，它会重写 composer.lock 并可能引入不兼容变更；日常开发和 CI/CD 中应优先使用 composer install 以确保依赖一致性与可复现性。
直接运行 composer update 会重写 composer.lock，但多数时候你并不需要它
除非你明确想升级依赖版本（包括次版本、补丁版本甚至主版本），否则不该用 composer update。它会根据 composer.json 中的版本约束重新解析整个依赖图，可能引入不兼容变更——哪怕只是 monolog/monolog 从 2.9.1 升到 2.9.2，也可能因底层行为微调导致日志格式异常。
- 日常开发中，只要没改
composer.json，就该用composer install：它只读取现有composer.lock，装出完全一致的依赖树 - CI/CD 流水线里必须禁用
composer update，否则每次构建结果不可复现 -
composer update默认启用--with-dependencies，连子依赖都会动；加--no-update-with-dependencies可限制只更新顶层包（但极少用）
composer update 后 composer.lock 没变？检查是否启用了 --dry-run 或锁文件被 Git 忽略
常见现象是执行完命令，composer.lock 时间戳没变、Git 状态显示无修改。大概率是误加了 --dry-run 参数，或者当前目录下 .gitignore 里写了 composer.lock（极少数项目会这么干，但违反 Composer 最佳实践）。
- 运行
composer update --dry-run只模拟计算，不写入任何文件 - 确认
composer.lock是否在 Git 跟踪中：git ls-files | grep composer.lock，为空则需先git add composer.lock - 某些 IDE（如 PHPStorm）会在后台静默执行
composer install，干扰你的手动操作，可关掉「Synchronize composer.json on changes」选项
只想更新某一个包，比如 guzzlehttp/guzzle，但避免牵连其他依赖
直接指定包名即可，Composer 会保留其余依赖的锁定版本，只升级目标包及其满足新约束的必要子依赖。
- 命令：
composer update guzzlehttp/guzzle - 如果它依赖的
psr/http-client版本范围太宽（如^1.0），而你当前锁的是1.0.1，升级后可能跳到1.0.3—— 这属于合理行为，不是 bug - 加
--with-all-dependencies会让它连带更新所有间接依赖（危险！慎用） - 若提示
Root composer.json requires guzzlehttp/guzzle ^7.0, found guzzlehttp/guzzle[dev-master, 7.x-dev] but these do not match，说明你本地分支或仓库配置异常，不是锁文件问题
CI 环境下 composer install 报错 Lock file operations: 1 install, 0 updates, 0 removals 后失败
这不是警告，是 Composer 在告诉你：composer.lock 里记录的某个包版本，在当前源（如 packagist.org）已不可用——可能已被删、被设为 private、或你配置了私有仓库但认证失败。
- 先跑
composer show -p看当前可用包源，确认是否漏配私仓地址 - 用
composer why-not vendor/package:version查哪个依赖阻止了安装（例如laravel/framework锁死symfony/console为5.4.*，但你要装6.0） - 若确定要更新锁文件，就在本地运行
composer update vendor/package --lock（注意--lock参数仅更新 lock 文件，不装包），再提交新 lock
composer.lock，而是判断「此刻该不该更新」——它本质是一份契约，改它等于改接口协议。很多线上故障，源头就是某次 composer update 没走 code review，悄悄越过了语义化版本边界。 
