报错“THESE PACKAGES DO NOT MATCH THE HASHES”是pip哈希校验失败，主因包括官方包更新、镜像同步滞后、本地缓存损坏或网络中断；推荐先执行pip cache purge清理缓存，再用--no-cache-dir重装，或删requirements.txt中--hash行后安装。
pip install 报错 “THESE PACKAGES DO NOT MATCH THE HASHES” 怎么办
这是 pip 在启用 --require-hashes 模式时的硬校验失败，不是警告，是直接中断安装。错误里会明确列出哪个包、期望的 sha256 值和实际算出的值——这两个字符串只要有一个字符不同，就说明文件内容已变。
常见原因包括：
- PyPI 上该包被重新上传（同一版本号，但内容变更，比如修复了 CVE 后重发）
- 你用了非官方镜像源，而该镜像同步滞后或缓存污染
- 本地 pip 缓存中存了旧版或损坏的 wheel 文件
- 网络代理/CDN 中途篡改或截断了下载流（尤其在企业出口或某些 ISP 环境下）
实操建议：
- 先清缓存：
pip cache purge，再重试安装 - 强制跳过缓存重拉：
pip install --no-cache-dir -r requirements.txt - 确认当前源地址：
pip config get global.index-url，和项目文档要求的是否一致 - 如果确定要更新哈希值（比如你信任新包），用
pip install --generate-hashes --dry-run -r requirements.txt 2>&1 | grep "sha256"提取新哈希，手动替换或用脚本更新requirements.txt
apt 下载 deb 包时提示 Hash Sum Mismatch 怎么定位
这类错误通常出现在 apt-get update 或 apt-get install 过程中，日志里会显示类似 Hash Sum mismatch 或 Failed to fetch ... Hash Sum mismatch。它和 pip 的哈希失败逻辑不同：apt 校验的是整个 Packages.gz 元数据文件或单个 .deb 的 SHA256 字段，不是用户可控的配置项。
真正的问题往往不在包本身，而在传输链路：
- 本地 apt 缓存损坏：
sudo apt clean清空/var/lib/apt/lists/和/var/cache/apt/archives/ - 代理或 ISP 中间设备（如透明代理、缓存网关）不支持 HTTP pipelining，导致响应体错乱 —— 此时需在
/etc/apt/apt.conf.d/99FixHashCheckSumError中写入：Acquire::http::Pipeline-Depth "0";Acquire::http::No-Cache "true"; - 源服务器返回了 304 Not Modified 但 ETag 不匹配，可临时禁用条件请求：
Acquire::http::Redirections "0";
注意：不要盲目 apt --fix-missing install，它不会重校验元数据，可能跳过真正出问题的包。
怎么验证一个已安装的 deb/rpm 包文件没被篡改
安装后的校验不是“多此一举”，而是确认 dpkg -i 或 rpm -ivh 过程是否完整落地。Linux 发行版原生提供对应命令，无需额外工具：
- Debian/Ubuntu 系统：
dpkg --verify 包名（输出为空表示全部文件 OK；dpkg --verify --show-files 包名可看具体路径） - RHEL/CentOS/Fedora 系统：
rpm -V 包名（输出如S.5....T. c /etc/config.conf表示 size、MD5、mtime 异常；.表示正常） - 若只想查某个文件归属：
dpkg -S /usr/bin/foo或rpm -qf /usr/bin/foo，再对其所属包做完整校验
这些命令校验的是包管理器数据库里记录的原始哈希（deb 用 md5sums，rpm 用 sha256），比手动 sha256sum 更可靠——因为它们还检查权限、属主、符号链接等元数据。
为什么自己用 shasum 算出来的值和官方公布的对不上
最常踩的坑是：没注意下载的是源码包（.tar.gz）还是二进制分发包（.whl、.deb、.rpm），或者解压后去校验子目录里的文件。官方发布的 SHA256SUMS 文件，几乎总是针对**原始下载文件本身**，而不是解压后的内容。
正确做法：
- 确保你
shasum -a 256 foo.tar.gz算的是那个刚下载完、未经任何处理的文件 - 确认下载过程没被浏览器自动解压（比如 Chrome 对
.zip的默认行为） - 核对大小：
ls -l foo.tar.gz和官网标称 size 是否一致，不一致直接重下 - 若官网只提供 GPG 签名（如 Linux 内核），应先用
gpg --verify SHA256SUMS.gpg SHA256SUMS验证清单真伪，再用清单校验文件
哈希本身没有“复杂逻辑”，但传输、缓存、解压、权限继承这些环节，每一个都可能悄悄改变字节流。校验必须卡在「下载完成但尚未解压」这个瞬间，否则就失去了意义。
