hash mismatch 是 Composer 校验失败，因下载包与 composer.lock 中记录的 SHA256 哈希值不一致，常见于缓存损坏、镜像同步延迟、手动修改 lock 文件或 vendor 残留。
composer install/update 报错 hash mismatch 是什么情况
这是 Composer 在校验包完整性时发现下载内容和 composer.lock 里记录的 SHA256 哈希值对不上。不是网络中断或权限问题，而是「文件确实被改过」——可能是缓存污染、镜像源同步延迟、本地修改了 vendor 里的文件，或者 lock 文件本身已过期但没更新。
常见错误现象包括：
Invalid archive signature: hash mismatchPackagevendor/packagehas a mismatching hash- 同一份
composer.lock在不同机器上反复报错
清除 composer 缓存并重试是最有效的第一步 Composer 会把下载的 zip 包缓存在本地，一旦缓存损坏（比如断电、磁盘写入失败），后续安装就会复用坏包，直接触发哈希校验失败。
实操建议：
- 运行
composer clear-cache，它会清掉~/.composer/cache下所有归档和元数据 - 再执行
composer install或composer update，让 Composer 重新下载全部包 - 如果用了国内镜像（如阿里云、腾讯云），可临时切回官方源验证：加
-vvv参数看实际下载 URL，或临时设composer config repo.packagist composer https://packagist.org
检查 composer.lock 是否被手动修改或混入脏内容
composer.lock 是二进制安全的快照文件，任何手动编辑（比如改版本号、删包、调格式）都会导致哈希失效。更隐蔽的是：Git 自动转换换行符（CRLF ↔ LF）、IDE 插件自动格式化 JSON、甚至复制粘贴时带了不可见 Unicode 字符。
判断方法：
- 对比
git status和git diff composer.lock，确认是否有非composer update引起的变更 - 用
composer validate --no-check-all检查 lock 文件语法合法性（虽不校验哈希，但能发现 JSON 错误） - 如果团队共用 lock 文件，确保所有成员使用相同 Git 设置：
git config core.autocrlf input（Linux/macOS）或false（Windows）
vendor 目录残留或部分写入失败也会引发哈希错乱
Composer 安装时是先解压到临时目录，再原子性地移动进 vendor/。如果中途被杀进程、磁盘满、或 vendor 下有只读文件（比如上次安装卡住留下的空目录），就可能让某几个包处于「半安装」状态——lock 记的是完整包哈希，而本地只有残缺文件。
实操建议：
- 删掉整个
vendor目录和composer.lock（仅限开发环境且确认无自定义修改） - 运行
composer install从头生成 lock 并安装（注意：这会忽略 lock 中的精确版本，等效于一次update） - 若必须保留 lock 的版本锁定，先
rm -rf vendor，再composer install --no-scripts避开 post-install-cmd 可能引发的额外写入干扰
-vvv 日志里比对下载 URL 和响应头里的 Content-MD5 才能定位。 
