直接结论：这不是包被篡改，90%是本地缓存损坏或requirements.txt里的hash过期；先运行pip cache purge，再检查镜像源或更新hash。
直接结论：这不是包被篡改，90% 是本地缓存损坏或 requirements.txt 里的 hash 过期了；先跑 pip cache purge，别急着加 --trusted-host 或跳过校验。
为什么 pip cache purge 是第一反应
pip 缓存目录里如果存了半截的 .whl 文件（比如下载中断、代理截断、磁盘写入失败），下次安装时它仍会复用——但计算出的 SHA256 自然和 requirements.txt 里声明的不一致。这种“哈希可重现失败”（Hash reproduction failure）本质是本地状态错乱，不是网络或权限问题。
-
pip cache purge安全、无副作用，不改配置、不切源、不绕过校验 - 执行后运行
pip cache info，确认Cache directory下的wheels和http子目录明显变空 - macOS/Linux 用户同样适用，无需 sudo
requirements.txt 里的 --hash 值过期了怎么办
哈希值不是永久有效的。当包作者发布新轮子（比如 numpy-1.26.4-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl），旧 hash 就失效了——这时 pip cache purge 没用，必须更新文件本身。
- 别手改
requirements.txt：容易漏掉多行--hash或格式错位 - 用
pip-compile从源头重建：pip-compile --generate-hashes requirements.in - 若只有
requirements.txt，可用pip install --dry-run --no-deps -r requirements.txt 2>&1 | grep "Collecting"辅助识别实际解析出的版本，再重新生成
--no-cache-dir 不是替代方案，只是临时验证手段
--no-cache-dir 不清理缓存，而是彻底绕过缓存逻辑——每次安装都强制重下载。它适合排查，但不适合解决哈希失败。
- 它会显著拖慢安装速度，尤其在带宽受限或离线环境
- 别和
--force-reinstall混用：后者触发依赖重解，可能引入新冲突 - 仅用于验证：比如
pip install --no-cache-dir -r requirements.txt成功了，才说明确实是缓存问题 - 某些系统级 pip（如 apt 安装的）拒绝写入用户缓存目录，此时
--no-cache-dir反而更可靠
清完缓存还报错？得往上游查
如果 pip cache purge 后重试仍提示 THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE，说明问题不在本地：
- 镜像源同步滞后：清华、豆瓣等源偶尔未及时同步 PyPI 上的新 wheel，导致 hash 不匹配
- 包作者主动替换 wheel：虽不推荐但允许，同版本号下二进制内容已变
- 你用的不是官方 PyPI 源，而是私有仓库或内部镜像，其 wheel 内容与 hash 声明不一致
- CI 环境中用了
--find-links指向本地 wheel 目录，但该目录里的 wheel 文件被手动替换了却没更新 hash
真正容易被忽略的是：带 hash 的 requirements.txt 无法直接支持 pip install -e . 开发安装；开发态建议用 pip-sync 替代，它会严格比对 hash 并拒绝不匹配项。
