根本原因是局域网中代理、缓存或防火墙等中间设备篡改wheel文件却未更新哈希，导致pip校验失败；应针对可信内网镜像配置require-hashes=false，而非全局禁用校验。
为什么 pip install 在局域网里总报 Hash mismatch？
根本原因不是 pip 本身坏了，而是局域网内常见的代理、缓存服务器或中间网关（比如企业防火墙、透明代理、HTTP 缓存设备）悄悄修改了下载的 wheel 文件内容，但没同步更新 Content-Length 或 ETag，导致 pip 校验时发现本地文件哈希和 PyPI 上记录的不一致。
典型现象：ERROR: Hash mismatch for package xxx，重试多次仍失败，换手机热点立刻成功——这基本能锁定是中间网络设备的问题。
- 不要盲目加
--trusted-host或--disable-pip-version-check，这些不解决哈希校验问题 - 禁用代理不一定管用：有些代理是“透明”的，你根本没配代理，但它依然在转发
- 公司内网 DNS 劫持 PyPI 域名到内部镜像源，但镜像同步滞后或校验逻辑有缺陷，也会触发哈希错乱
怎么绕过校验又不降低安全性？
最稳妥的做法是让 pip 跳过对特定源的哈希校验，而不是全局关闭。关键是只对可信的内部镜像源禁用校验，同时保留对官方 PyPI 的完整验证。
- 确认你实际使用的源地址：运行
pip config list或检查$HOME/.pip/pip.conf（Linux/macOS）或%APPDATA%\pip\pip.ini（Windows） - 如果走的是内网镜像（如
https://pypi.example.com/simple/），在配置中加这一行：trusted-host = pypi.example.com，再加一行：index-url = https://pypi.example.com/simple/ - 关键一步：在该源配置下追加
require-hashes = false—— 注意，这是 per-index 设置，不是全局开关 - 避免用
--no-deps或--force-reinstall来掩盖问题，它们可能跳过依赖树里的校验，但治标不治本
临时调试：快速定位是哪个环节篡改了文件
把下载过程拆开看，就能定位篡改点。核心思路是：对比原始文件哈希 vs pip 缓存里文件的哈希。
- 先用
pip install --download /tmp/wheels -v package_name下载 wheel 到本地目录，加上-v看详细日志，记下实际下载 URL - 用
curl -L -o /tmp/fetched.whl "URL"手动下载同一链接，再用sha256sum /tmp/fetched.whl计算哈希 - 对比 pip 日志里打印的期望哈希（形如
Expected sha256 xxx, got yyy），如果手动下载的哈希和 “got” 一致，说明问题出在 pip 下载过程中被中间设备改写；如果手动下载的哈希就和 “expected” 不符，说明镜像源本身数据已损坏 - 注意：某些企业镜像会把
.whl解压重打包再塞回，导致元数据（如RECORD文件）哈希变化，这种必须联系运维更新镜像同步策略
长期方案：别让 pip 自己校验，改用可信通道分发
在强管控局域网里，指望 pip 过校验不是长久之计。真正可靠的解法是脱离 HTTP 下载路径，改用预校验过的离线分发机制。
- 用
pip wheel --no-deps --wheel-dir ./wheels package_name在干净网络环境（如家里、CI 机器）提前打包好 wheel，并用pip hash ./wheels/*.whl记录所有哈希值 - 把 wheel 文件和哈希清单一起拷进内网，用
pip install --find-links ./wheels --no-index --trusted-host localhost package_name安装 - 如果团队规模较大，建议搭一个轻量
devpi或artifactory实例，上传 wheel 时强制校验签名，客户端只认这个源，彻底规避中间篡改 - 切忌把
--hash参数硬编码进 requirements.txt：一旦 wheel 更新，旧 hash 就失效，反而增加维护负担
局域网的“安全策略”常常以牺牲完整性校验为代价，这时候得接受一个事实：校验不是消失，而是要换个地方做——要么提前做，要么换通道做。指望 pip 在链路已被污染的情况下完成端到端校验，本身就是个伪命题。
