pip cache purge是最常用且安全的缓存清理方式，可解决八成以上哈希不匹配错误；它清除损坏或不完整的下载缓存，但无法修复哈希过期问题，后者需用pip-compile --generate-hashes更新requirements文件。
直接清缓存最常用也最安全，pip cache purge 能解决八成以上的 THESE PACKAGES DO NOT MATCH THE HASHES 报错——前提是问题真出在缓存里。
为什么先跑 pip cache purge
pip 缓存会保存已下载的 .whl 或 .tar.gz 文件。如果某次下载被中断、代理截断、磁盘写入失败，缓存里就可能存着一个不完整的包。下次安装时 pip 仍会复用它，但算出来的 SHA256 值自然和 requirements.txt 里写的对不上。
执行 pip cache purge 后，再重试安装，多数情况立刻变绿。
- Windows 用户直接运行：
pip cache purge - macOS / Linux 用户同样只需：
pip cache purge - 验证是否清空：运行
pip cache info，看Cache directory对应路径下的wheels和http子目录是否明显变空
--no-cache-dir 是排查手段，不是日常解法
它不清理缓存，而是彻底绕过缓存逻辑——每次安装都强制重新下载所有包。适合临时验证是不是缓存惹的祸，但不适合反复用。
尤其在带宽受限或网络慢的环境（比如树莓派、CI 构建机），它会让安装时间翻倍甚至超时。
通过 Pipedream Connect 将 OpenClaw 代理连接到数千个应用，实现每个代理的 OAuth 隔离，提供一流 MCP 工具以及实时已连接账户发现
- 仅用于排查：
pip install --no-cache-dir -r requirements.txt - 别混用
--force-reinstall：除非你明确要覆盖已装版本，否则它会触发额外依赖重解，可能引发冲突 - 某些系统级 pip（如 Ubuntu apt 安装的）可能无权写用户缓存目录，此时
--no-cache-dir反而更可靠
哈希值本身过期了，purge 就没用
当包作者发布新版 wheel（比如 requests-2.32.3-py3-none-any.whl），旧 hash 就失效了。这时候清缓存、换源、重试全无效，必须更新 requirements.txt 里的哈希值。
手动改容易漏掉多行 --hash 或格式错位，推荐用工具生成：
- 确保已装
pip-tools：pip install pip-tools - 如果有
requirements.in，运行：pip-compile --generate-hashes requirements.in - 如果只有
requirements.txt，可用pip install --dry-run --no-deps -r requirements.txt 2>&1 | grep "Collecting"辅助识别实际拉取的版本，再重建
PyCharm 控制台报 Hash missing for requirement
这是启用了 --require-hashes 模式，但 requirements.txt 里某行没写 --hash=sha256:xxx。不是版本错，是校验缺失。
典型错误写法：pandas==2.1.0；正确写法必须带哈希：
pandas==2.1.0 \<br> --hash=sha256:abc123...（注意反斜杠换行）
- 别手敲哈希值，用
pip-compile生成 - PyCharm 默认不会自动加
--require-hashes，检查 Terminal 配置或 Run Configuration 是否手动加了该参数 - 若只是本地开发调试，可临时去掉该参数，不用强校验
真正麻烦的是哈希值和包内容不一致却找不到源头——比如 PyTorch 的 CPU 版本链接没变但 wheel 内容更新了，或者公司内网镜像同步滞后。这种时候得比对 Expected sha256 和 Got 的值，再决定是更新 hash、切源，还是临时跳过校验。
