composer update --lock 仅刷新 composer.lock 中的 dist 哈希值而不升级依赖，不修改 vendor/ 和 composer.json；它跳过依赖解析与安装，仅重算并写入 sha256 等哈希，用于修复因镜像同步延迟或 dist 包重推导致的哈希不匹配问题。
composer update --lock 只刷新 hash 不升级依赖
这是 Composer 5.0+ 引入的明确行为：执行 composer update --lock 会重新计算并写入所有已锁定包的 dist 哈希值（如 sha256），但完全跳过版本解析、依赖求解和 vendor 文件更新。它只动 composer.lock，不动 vendor/ 和 composer.json。
常见错误现象：composer install 报 Package operations: 0 installs, 0 updates, 0 removals 却仍提示哈希不匹配；CI 构建因哈希失效失败，但你确认没改任何依赖——大概率是源仓库的 dist 包被重推或镜像同步延迟导致哈希漂移。
- 必须确保当前
composer.json和composer.lock的顶层依赖声明完全一致，否则命令会直接报错退出 - 该命令不读取
--with-dependencies或--no-install等其他 flag，加了也无效 - PHP 版本、平台配置（如
ext-zip是否启用）会影响哈希计算逻辑，跨环境执行前先核对composer config platform
为什么不能用 composer update --dry-run 替代
composer update --dry-run 是模拟完整更新流程，它会走依赖求解、版本比对、甚至尝试下载元数据，只是不真正写文件。它不会刷新 lock 中的哈希，也不会校验现有 vendor 是否匹配 lock——它只告诉你“如果真跑 update 会装哪些包”。所以它解决不了哈希不一致问题。
使用场景：你想预判一次 composer update 会不会引入新版本或破坏兼容性，而不是修复 lock 文件本身。
-
--dry-run输出里出现Nothing to install, update or remove≠ lock 哈希正确；它只说明版本无变化，不校验哈希 - 若 lock 文件中某包哈希已失效，
--dry-run可能静默跳过警告，而真实install时才爆错 - 它的性能开销远高于
--lock，尤其在大型项目中会明显卡顿
什么时候必须手动改 lock 文件里的 hash
极少数情况 composer update --lock 也救不了：比如你用私有 repo，但它的 packagist.org 元数据缓存已失效，Composer 拿不到正确的 dist 信息；或者你本地 vendor 是从另一台机器复制来的，但那台机器用了不同版本的 Composer（哈希算法有细微差异）。
这时只能手动编辑 composer.lock，定位到对应 package 的 dist 块，替换 sha256 字段值。别碰 source 或 type 字段。
- 哈希值必须和实际 dist 包完全一致，可用
shasum -a 256 vendor/{vendor}/{package}/composer.json反向验证（前提是该包确实是 dist 安装的） - 修改后务必运行
composer validate --strict，检查 lock 文件语法和结构合法性 - Git 提交时注意：不要只提交 lock 文件改动而不附带说明，否则协作同事无法理解为何哈希突变
CI/CD 中自动刷新 lock 的安全边界
有些团队在 CI 流水线开头加 composer update --lock && git diff --quiet composer.lock || (git add composer.lock && git commit -m "chore: refresh lock hashes")，意图自动兜底。这看似省事，实则危险。
风险点在于：一旦上游镜像源临时返回脏数据（比如 CDN 缓存污染），这个脚本就会把错误哈希永久写进主干。下次本地 install 就全崩。
- 建议仅在 nightly job 或专用 infra 分支中运行该逻辑，禁止在 PR 或 main 分支的构建中自动提交 lock
- 更稳妥的做法是让 CI 失败并报警，由人介入判断是否真需刷新——毕竟哈希不一致背后可能是安全事件
- 若坚持自动化，至少加上校验：用
composer show {package} --no-ansi确认 dist URL 可访问且返回 200，再执行--lock
哈希刷新看着简单，但它紧贴 Composer 的包完整性校验机制底层。一个错位的 sha256 值，可能让整个部署链路在最后一步静默失败。
