composer update 会重写 composer.lock 并按规则重算依赖树，而非同步远程状态；应优先用 install 还原环境，慎用 update 避免未测变更。
composer update 会改 lock 文件，但不等于同步远程依赖
执行 composer update 的本质是根据 composer.json 重新解析依赖图，然后拉取满足约束的最新可用版本（受 minimum-stability 和 prefer-stable 影响），并更新 composer.lock。它不是“把本地已安装包和远程仓库对齐”，而是“按规则重算一次依赖树”。如果你本地已有某些包，但 lock 文件里记录的是旧版本，update 后它们会被替换——哪怕远程没变，只要解析结果变了就会动。
常见误操作：在团队协作中直接运行 composer update 提交新的 lock，却没意识到这可能升级了某个间接依赖（比如 monolog/monolog 从 2.8.0 升到 2.9.0），而该变更未经过测试。
- 想“同步”远程状态，应先确认
composer.json是否准确描述了预期依赖 - 若只是想确保本地与
lock一致，用composer install（不带--no-lock） -
composer update --dry-run可预览实际会更新哪些包及其版本变化
composer install 不联网也能还原环境，但前提是 lock 文件可信
composer install 默认跳过依赖解析，只读 composer.lock 并按其中精确版本下载/软链接包。这意味着：即使 Packagist 宕机、网络不通，或某包已被作者删库，只要 lock 里记录的 dist URL 还能访问（或缓存存在），就能完成安装。
关键限制在于：lock 文件必须由可信来源提供。如果它是从别人分支复制来的，且对方曾手动编辑过 lock（比如改了 dist/sha256），install 可能校验失败并中断。
- CI 环境应始终用
composer install，禁用update - 本地开发若需复现线上环境，优先
git checkout对应 commit 的lock文件再install -
composer install --ignore-platform-reqs仅绕过 PHP 扩展等平台检查，不跳过lock校验
只更新单个包时，lock 文件仍会重写，但其他依赖版本不变
运行 composer update vendor/package-name 会强制重新解析该包及其子依赖，但会锁定其余所有包的版本（即保留 lock 中原有记录）。不过，lock 文件本身仍会被完全重写——时间戳、排序、甚至 JSON 格式都可能变化，导致 Git 脏 diff。
