直接运行 composer clear-cache 能解决“无法获取包的哈希值”错误，因其清除 cache/repo/ 下损坏的 packages.json 元数据（含 dist.shasum），但不修复依赖冲突、镜像延迟或 vendor/ 损坏。
直接运行 composer clear-cache 就能解决“无法获取包的哈希值”这类报错，但前提是问题真出在本地元数据缓存损坏上——它不修依赖冲突、不绕过镜像延迟、也不恢复被手动删坏的 vendor/。
为什么会出现“无法获取包的哈希值”错误
这个错误通常不是 Composer 本身坏了，而是它在验证包完整性时，拿不到或读错了缓存里的元数据（比如 packages.json 快照里的 dist.shasum 字段）。常见触发场景包括：
- 你刚切换过镜像源（比如从阿里云切回官方源），但
~/.composer/cache/repo/里还留着旧源的元数据 - 手动编辑或误删过
~/.composer/cache/repo/packagist.org/下的 JSON 文件 - 网络中断导致某次
composer update半途退出，元数据写入不完整 - 公司私有 Packagist 镜像同步失败，本地缓存却没刷新，Composer 还在用失效索引查哈希
composer clear-cache 实际清掉哪些东西才管用
这条命令不是“清空所有缓存”就完事，关键在于它会重置三类缓存，而“哈希值缺失”问题基本只和其中一类强相关：
-
cache/files/：所有已下载的.zip包——跟哈希校验无关，清了只是下次重下 -
cache/vcs/：Git 克隆的裸仓库——不影响哈希计算 -
cache/repo/：这才是重点。里面存着每个源（如packagist.org）返回的packages.json快照，含所有包的版本列表、dist.url和dist.shasum。删掉它，下次composer update才会重新拉最新元数据
注意：cache/repo/packagist.org/ 被清空后，首次 composer update 会明显变慢，因为要重建整个索引——这是正常现象，不是失败。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
清完还是报错？先别急着重装 PHP
如果执行 composer clear-cache 后仍提示哈希缺失，大概率问题不在缓存本身，检查这几个点：
- 确认你没在
composer.json里写错包名或版本约束，比如"monolog/monolog": "3.0"实际应为"^3.0" - 运行
composer config -g repo.packagist.org看是否指向了异常 URL（比如拼错成https://packagist.com） - 临时禁用镜像源测试：
composer config -g repo.packagist.org https://packagist.org，再跑一次composer update --no-cache - 检查
composer.lock是否被 Git 忽略或手动修改过——它里面的shasum字段若为空或非法，也会触发同类报错
不想全量清？手动只动 repo/ 更精准
composer clear-cache 是全量操作，如果你只想救哈希问题又怕影响其他缓存（比如想保留 vcs/ 加速私有包克隆），可以手动清理：
- 先查路径：
composer config --global cache-dir - 进到
repo/子目录：cd $(composer config --global cache-dir)/repo - 删掉对应源的文件夹（国内用户常是
packagist.laravel-china.org或packagist.phpcomposer.com）：rm -rf packagist.laravel-china.org - 不建议删
packagist.org文件夹本身，只删其子目录下的 JSON 文件；否则首次更新会卡很久
手动删比 clear-cache 少清几百 MB，但对哈希问题效果一致——毕竟出问题的从来就只是那一层元数据。
