应使用 composer install 而非 update 来严格按 composer.lock 还原依赖，避免版本变动；若 lock 文件元数据需刷新但不改版本，用 composer update --lock；autoload 未更新时需手动执行 composer dump-autoload。
为什么 composer update 会改版本号而你不想动？
你手头的 composer.lock 文件已经稳定，所有依赖版本被精确锁定，但某次部署后发现本地 vendor/ 缺文件、autoload 错乱，或 CI 报 “Class not found”——问题往往不是版本不对，而是 vendor/ 和 lock 文件不一致。此时你真正需要的是「重装」而非「升级」，composer update 默认会按 composer.json 的约束重新解析依赖树，很可能升掉次版本甚至小版本；而 composer install 才是唯一尊重 lock 文件、只按它还原依赖的命令。
composer install 就是你要的“强制刷新 lock”操作
composer install 不读 composer.json 的版本范围，只严格对照 composer.lock 中记录的每个包名、版本、哈希值、安装路径和 autoload 映射，完整重建 vendor/。它不会修改 lock 文件本身（除非加 --lock 参数，但那是另一回事）。
常见误操作和应对：
- 执行了
composer update后后悔了？立刻git checkout composer.lock恢复，再跑composer install -
vendor/被手动删过或混入了非 Composer 安装的文件？先rm -rf vendor/，再composer install - CI 环境提示 “lock file is not up to date with composer.json”？说明
composer.json被改过但没运行composer update更新lock——这不是当前问题，别强行install，应先确认是否真要保留旧 lock，再决定用update --lock或回退 json 修改
真要“不改变版本号但更新 lock 文件本身”？只有 composer update --lock
这个命令不安装任何包，也不读 composer.json 的版本约束，只做一件事：按当前 composer.lock 里已有的包列表，重新生成其哈希值、zip 下载 URL、autoload 配置等元数据。适用于以下场景：
审查 Next.js App Router 代码库，检查 React Server Component 边界错误、请求瀑布、客户端/服务端反模式以及 Core Web Vitals 风险...
- 你确定所有包版本没变，但想刷新 lock 文件里的 dist source 哈希（比如修复因镜像同步延迟导致的校验失败）
- 项目迁移到新平台（如从 GitHub 切到 Gitee 镜像），需更新 lock 中的 repository URL 字段
- PHP 版本升级后，某些包的
platform-check失败，而你又不想动依赖版本——--lock会重算兼容性标记
注意：composer update --lock 不会改变任何 "version" 或 "source" 中的 commit hash，但会重写整个 lock 文件（时间戳、哈希值、URL 等字段会变），所以 git diff 一定有变化。
容易忽略的细节：autoload 重建必须靠 dump-autoload
即使 composer install 成功，如果新增了类、改了命名空间、或用了 psr-4 映射外的目录结构，vendor/autoload.php 可能没及时更新。这不是 lock 或 install 的问题，而是 autoload 缓存滞后。
解决方式很简单：
- 运行
composer dump-autoload（简写composer du）强制重生成 autoload 映射 - 若用了优化选项（如
--optimize或--classmap-authoritative），确保开发时没误开启——它们会让新增类在未重新 dump 前不可见 - 某些 IDE（如 PHPStorm）会缓存类索引，dump 后建议清空 IDE 的 index 缓存
最典型的“看起来 install 成功但类找不到”问题，八成卡在这一步，而不是 lock 或版本本身。
