包管理器国内源

装依赖慢、超时、卡在 downloading 时,先把源换成国内镜像试试。每条都给出设置、验证和恢复官方源三条命令,改坏了能一键改回来。

显示 32 / 32 条配置

换源之前先想清楚慢在哪

国内镜像解决的是「到境外源站的网络慢」,如果你的瓶颈其实是别的东西,换源不会有任何帮助。常见的几种情况:依赖本身很大(比如装了 CUDA 相关的 PyPI 包),镜像再快也要下载几百 MB;包在境外源上有而镜像是空的(发行版仓库的 backports 源、小众语言生态经常有这种情况);或者公司网络要走代理,那正确做法是配置 npm config set proxy、pip --proxy、HTTP_PROXY 环境变量,而不是换 registry。

另外要注意配置文件的作用范围。npm 有 user 级(~/.npmrc)和 project 级(项目里的 .npmrc)两层,project 级会覆盖 user 级,所以一个检出的项目可能带着自己的 registry 设定让你以为换源没生效。pip 同理,pip config list -v 能把所有生效的配置文件路径列出来。Maven 的仓库配置还可能被 <mirrors> 与 <repositories> 的组合拦掉,改之前先确认没有 mirrorOf 把请求全导向了别处。

同步延迟是唯一没法消除的代价

镜像不会实时同步上游。各家的策略不同:npm 镜像通常几分钟内就能同步到新发布的包,PyPI 镜像大约 5~15 分钟,conda 一般按小时,Docker Hub 的镜像站同步最慢,官方镜像仓库的 tag 更新可能滞后数小时甚至更久。刚发布的版本在镜像上找不到是正常的,不是镜像坏了。

这个延迟会带来几个具体现象:CI 里锁定了刚发布不久的版本,本地机器拉不到;上游作者紧急撤回(yank)了一个包,镜像上还能装到;依赖锁定文件里的 integrity 校验和与镜像返回的内容不一致(因为镜像缓存了旧版本)。遇到这些先等一会儿再试,或者临时切回官方源确认不是自己代码的问题。

安全上的取舍

换成第三方镜像,等于把「你安装的每一个依赖」交给镜像运营方分发。主流镜像(阿里云、腾讯云、华为云、清华 TUNA、中科大 USTC、npmmirror)是可信的,但要理解他们的信任模型:镜像是只读转发上游文件、按上游的校验和验证后再缓存,理论上不会篡改内容;可一旦镜像被入侵或上游被投毒,你拿到的就是被改过的包。

所以有两点值得坚持:一是优先用带签名校验的生态(apt/dnf 的仓库签名、Maven 的 checksum、npm 的 integrity 哈希),校验失败时千万不要用 --force、--no-check-certificate、trusted-host 这类参数糊过去;二是不要为了图快把 sslVerify=false、strict-ssl=false 写进配置,那会让中间人有机会直接替换包内容。企业内网私有的 Nexus / Artifactory 代理则和公网镜像不同——它们通常会缓存并保留审计记录,安全性取决于你们自己的运维水平,用之前确认一下是谁在维护。

企业内网代理和公网镜像的差别

公网镜像是「大家一起用的缓存站」,内网代理是「只服务你们自己的缓存」。内网代理的好处是首次拉过的包后面都走内网、可以托管私有包、能加审计和漏洞扫描;代价是首次拉取仍然要出公网,而且代理自身的存储和带宽可能成为瓶颈,还有清理策略过激导致缓存频繁失效的问题。很多公司是两者叠加:内网代理的上游配成国内公网镜像。

最后提醒一句:本页命令是各镜像官方文档与社区通行写法的汇总,取的是「写进配置文件永久生效」这种形式。不同发行版(Debian 用 /etc/apt/sources.list 或 sources.list.d/,新版 Ubuntu 24.04 起用 deb822 格式的 .sources 文件)、不同工具版本(Docker 的 daemon.json 配置、Gradle 的 init.gradle 与 settings.gradle)写法会有差异,动手前最好对着官方文档核一遍当前版本的正确格式。