银河麒麟V10换源全攻略：apt、pip、npm、conda与离线方案-开发者社区

单位新装了几台银河麒麟 V10 的工作站，系统装完后的第一件事，就是把软件源全部换成国内镜像。这个动作在麒麟系统上太常见了，因为默认源虽然能用，但在很多网络环境下动不动就超时、404，你敢直接把apt install丢给用户，他五分钟之内就会回来找你“系统坏了”。其实系统没坏，是源没配好。

这篇不绕弯子，就讲银河麒麟系统怎么换源，并把 apt、pip、npm、conda 这些常用包管理器的换源方法一次性讲透，外加离线环境下的“源替代”思路和换源后的排坑记录。适合刚接触麒麟系统、或者在单位机房里负责维护麒麟机器的朋友，无论你是用 x86 还是 ARM 架构，思路基本通用。

1. 动手之前：先把系统版本和源结构看清

1.1 银河麒麟的源设计思路

银河麒麟 V10 是 Debian 系的系统，包管理工具是 apt，安装软件最常用的命令就是apt install xxx。它不像 CentOS/RHEL 那样用 yum/dnf，所以网上那些 CentOS 换源的教程在这里基本不适用。银河麒麟默认的软件源指向官方仓库，这个仓库的特点是“全但网络环境不稳定”，内网机器更是完全访问不到。

换源本质上就是把apt从默认源指向的服务器地址，改成离你近、速度快、同步完整的镜像地址。这个过程不改变系统的包管理逻辑，只是换了一个“取货仓库”。理解这一点很重要，因为很多人误以为换源要重装系统、改配环境变量，实际上你只需要动一个文本文件就够了。

另外要提醒一句：银河麒麟的源里不只是单纯的应用程序，还有麒麟桌面环境的组件、系统底层库、驱动包等。所以源的选择直接关系到系统稳定性和安全性，不能拿网上随手抄的一段 Ubuntu 源就直接贴进去。

1.2 一条命令确认版本和架构

换源之前最重要的一件事，是确认你的系统是 V10 的哪个小版本、CPU 是 x86_64 还是 aarch64。虽然 apt 源配置大体相似，但 V10 的 SP1、SP2、SP3 路径有差异，ARM 和 x86 源很多时候也不通用。别小看这一步，很多人换完源 update 报 404，八成就是版本写错了。

可以用这几个命令来确认：

nkvers

这是麒麟系统的专属命令，执行后直接显示当前内核版本和麒麟发行版名称。我看到很多教程里没有提这个命令，但它在排障时特别有用。

cat /etc/kylin-release cat /etc/os-release uname -m

cat /etc/os-release会显示比较详细的系统名称和版本号，uname -m则用来判断架构：输出x86_64说明是 Intel/AMD 平台，输出aarch64说明是飞腾、鲲鹏、麒麟芯片这类 ARM 平台。

以我手头这台机器为例，nkvers输出里能看到 Kylin V10 的标识和内核版本号，uname -m显示x86_64。那我在配置源的时候，就可以按 V10 x86_64 的通用格式来处理，遇到 SP 版本差异时再回去翻源文件确认，这样心里有底。

1.3 源文件在哪，备份怎么做

Debian 系软件的源文件默认是/etc/apt/sources.list，银河麒麟还可能有/etc/apt/sources.list.d/目录，里面放着一些第三方软件的独立源文件。换源之前建议都备份一遍：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak.$(date +%Y%m%d) sudo cp -r /etc/apt/sources.list.d /etc/apt/sources.list.d.bak.$(date +%Y%m%d)

备份不是形式主义。真把源改坏了，或者系统更新后出现依赖问题，你随时可以一条命令换回原来的状态。改源这事本身没有太大风险，风险全在你手里的初始配置是不是不可恢复。我见过有人改了源之后 apt 报错，又忘了原来的源长什么样，最后只能网上找别人的配置来猜，折腾一整天。所以备份这步真的别跳。

做完备份，再用cat /etc/apt/sources.list看一眼默认源文件内容。有些版本的系统默认源文件可能被拆分到sources.list.d里，如果sources.list是空的或者只有注释，重点去sources.list.d目录里找。这一步能帮你判断到底改哪个文件。

2. apt 换源实操：照着做就能跑通的步骤

2.1 看懂源文件的基本结构

先看一段典型的银河麒麟 V10 官方源配置，注意这是参考格式，不是所有版本都一样，以你本机原来的文件为准：

deb http://archive.kylinos.cn/kylin/KYLIN-V10 SP1 main restricted universe multiverse deb http://archive.kylinos.cn/kylin/KYLIN-V10 SP1-updates main restricted universe multiverse deb http://archive.kylinos.cn/kylin/KYLIN-V10 SP1-security main restricted universe multiverse

拆开来看就很好理解了：

archive.kylinos.cn是官方源服务器地址；
/kylin/KYLIN-V10是仓库路径，不是 Ubuntu 的ubuntu/路径；
SP1是发行版代号，如果你的系统是 SP2/SP3，就要对应修改；
main restricted universe multiverse是仓库组件分类，分别代表官方支持、受限软件、社区维护、非自由软件。

把这三行结构看懂，后面换源的核心思路就清晰了：保住结构，替换地址。不要整段重写，只需要把服务器地址替换成镜像站地址。

2.2 换成国内镜像源的具体操作

国内几个主流镜像站都同步了麒麟源，我个人用得最多的是清华 TUNA 镜像。操作思路其实很简单，把源文件里的http://archive.kylinos.cn/kylin整体换成镜像站对应路径就行了。

用 sed 一条命令就能完成替换：

sudo sed -i 's|http://archive.kylinos.cn/kylin|http://mirrors.tuna.tsinghua.edu.cn/kylin|g' /etc/apt/sources.list

执行完以后用cat /etc/apt/sources.list | head -n 10看一下结果，确认地址替换对了。如果源文件里写的是https://开头，把 sed 里的http换成https再执行一次即可。

如果你更习惯手动编辑，直接sudo vim /etc/apt/sources.list，把开头的地址改掉，保存退出，效果一样。

借这个机会泼一盆冷水：网上很多教程让你直接把 Ubuntu 18.04/20.04 的源整段贴进麒麟系统，这种操作非常危险。银河麒麟虽然基于 Ubuntu 的包管理框架，但对不少包做过版本调整和补丁，直接把 Ubuntu 源搬过来，最轻的是软件版本“莫名其妙不兼容”，最重的是 apt 依赖关系直接崩掉，装什么软件都会报依赖错误。我一直的原则是：麒麟机器优先用麒麟官方源或镜像站同步的麒麟源，不要跟 Ubuntu 源混着用。

2.3 换源后必做的三步验证

源改完之后，一定要跑一遍下面的流程，别改完就以为万事大吉。

第一步，刷新软件列表：

sudo apt update

这一步如果报错，下面第 5 章有详细的排查表，先对应看一下。正常情况下应该能看到各个仓库的索引文件被正常拉取，最后的输出统计是N packages can be updated之类的结果。

第二步，先别急着升级，看看到底有哪些包要动：

sudo apt upgrade --dry-run

--dry-run参数只预览不执行。这一步的目的是让你心里有数，避免在没看清单的情况下直接升级几十个包，结果把桌面环境或者某个正在用的驱动搞坏了。特别是带kylin-前缀的系统组件，要格外留意。

第三步，挑一个常用软件实测安装：

sudo apt install htop

如果 htop 能正常装上，说明换源后的整个链路是通的，后面再用其他软件就不会有大问题了。

2.4 应用商店和源之间的联动关系

很多用户反馈“应用商店打不开”“软件一直下载中”，然后把问题归咎于系统。这里要说明一下：麒麟的应用商店有独立的更新通道，但底层依然依赖 apt 源。如果你换了源之后应用商店还是一直转圈，建议去/etc/apt/sources.list.d/看看，有些版本的商店源是单独存放的，同样需要一并进行替换或调整。

另外，应用商店里某些软件在命令行里也能装，对应的包名可能和你预想的不一样。遇到商店里下载卡住的情况，可以先在命令行里搜一下包名，用 apt 装，往往更快更稳定。

3. 开发环境也跟着换：pip、npm、conda

系统源换完之后，很多人容易忽略开发环境自身带的包管理器。它们默认指向的公共源，在某些办公网络里又慢又容易断，换源后的体验差异非常明显。

3.1 pip 换源的正确姿势

pip 换源我习惯直接写配置文件，不依赖命令行参数临时指定。因为临时指定参数只对当前命令生效，写进配置文件才是一劳永逸。

配置文件的位置有讲究，个人配置是~/.config/pip/pip.conf或~/.pip/pip.conf，全局配置是/etc/pip.conf。不确定当前系统读的是哪个，先跑下面这条命令看实际读取路径：

pip config debug

用起来最顺手的配置写法是：

[global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple trusted-host = pypi.tuna.tsinghua.edu.cn disabled-pip-version-check = true

保存后执行pip config list确认生效。之后安装 Python 包的速度提升会非常明显，之前动不动要等一分钟的pip install requests，换完源基本几秒搞定。

国内可用的 PyPI 镜像不止清华一家，列个参考表：

镜像站	地址
清华 TUNA	https://pypi.tuna.tsinghua.edu.cn/simple
阿里云	https://mirrors.aliyun.com/pypi/simple/
腾讯云	https://mirrors.cloud.tencent.com/pypi/simple/
中科大 USTC	https://pypi.mirrors.ustc.edu.cn/simple/

选哪个没有标准答案，建议都试一次，选你认为最稳的。如果是在内网环境，还可以自己搭一个私有 PyPI 源，团队共享效率最高，这个属于进阶玩法，后面单独讲。

3.2 npm 源切换

npm 换源比 pip 更简单，只需要记住两条命令：

npm config set registry https://registry.npmmirror.com npm config get registry

第一条设置全局 registry，第二条验证是否生效。这里特别提醒一下：npmmirror 是淘宝 npm 镜像的新域名，老域名registry.npm.taobao.org已经停止同步，网上很多旧教程还在用老域名，容易踩坑。

如果项目里有.npmrc文件，项目级的 registry 配置会覆盖全局配置，这一点在排查“为什么换了源还是慢”的时候要记住。同样的方法也适用于 yarn 和 pnpm，它们各自有对应的 config 命令，但核心改动都是指向同一个国内镜像地址。

3.3 conda 换源和 channel 顺序

conda 在数据分析场景里太常见了，但它的源配置有点绕。核心思路是添加国内镜像 channels，然后把defaults关掉或者移动到最末尾，否则 conda 还是会先去访问默认源。

推荐命令：

conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/ conda config --set show_channel_urls yes conda config --remove channels defaults

前两条把自己常用的 channel 加到最前面，第三条让 conda 显示每个包来自哪个源，方便排查，第四条是去掉默认源。

如果之后遇到环境解析很慢，先检查~/.condarc文件，确认 channel 顺序、有没有残留的defaults。conda 这种工具，源配置出问题的表现通常不是直接报错，而是“卡在 Solving environment”半天没动静，这其实就是在反复尝试不可达的地址，需要手动清理配置。

4. 离线环境怎么用“源”：离线安装 nginx 的思路

换源这个话题往深处走，必然会遇到一类特殊场景：目标机器完全不能访问外网，甚至内网也没有可用的软件源。最常见的任务就是离线安装 nginx、离线装 Python 包。这里以离线安装 nginx 为例，把三种可行思路讲清楚。

4.1 思路一：把 deb 依赖包连带搬过去

这是最简单直接的方法，适合目标机器和源机器都是同版本银河麒麟的场景。在一台能联网的同版本麒麟机器上先更新源，然后执行：

sudo apt update mkdir /tmp/nginx-pkgs sudo apt-get install --download-only nginx cp /var/cache/apt/archives/*.deb /tmp/nginx-pkgs/

--download-only是核心参数，它只下载不安装，下载好的 deb 包会缓存在/var/cache/apt/archives/下。把这些 deb 文件打包传输到离线机器，然后在目标机器上执行：

cd /tmp/nginx-pkgs sudo dpkg -i *.deb

如果 dpkg 提示某些依赖缺失，说明目标机器上缺的包不在下载列表里，需要用apt-cache depends配合递归参数再补一轮依赖。更稳妥的做法是在目标机器上用sudo apt install ./*.deb，让 apt 自己把依赖关系理清楚。

这个方法的关键是两边系统版本要一致。跨版本移植 deb 包容易碰到动态库版本对不上的问题，比如在 V10 SP1 上下载的包，拿到 V10 SP3 上装可能就报libssl.so.1.1 not found之类的错误。

4.2 思路二：源码编译安装

如果离线机器上连对应的 deb 包仓库都没有，那就回到传统路线——源码编译。

编译 nginx 需要准备三样东西：nginx 源码、编译工具链（gcc、make 等）、依赖库的开发包（pcre2、zlib、openssl 等）。在离线环境里，工具链本身就是一个难题，所以这个方案适合机器上已经装了 gcc 的环境，或者你提前把编译工具链都搬了过去。

下载源码后在离线机器上执行：

tar -xzf nginx-1.26.0.tar.gz cd nginx-1.26.0 ./configure --prefix=/usr/local/nginx --with-http_ssl_module make -j$(nproc) sudo make install

编译安装很灵活，可以按需裁剪模块，但坑也不少。最常见的是./configure阶段提示缺少某个库，此时只能去下载对应库的源码再编一遍。所以离线编译前，一定要在联网机器上把依赖先列清楚，能省很多来回。

4.3 思路三：Docker 镜像搬运与内网源

如果离线机器上有 Docker 环境，第三种思路更省心：在联网机器上拉一个现成的 nginx 镜像，打包带走：

docker pull nginx:stable docker save nginx:stable -o nginx.tar

把nginx.tar复制到离线机器，然后执行：

docker load -i nginx.tar

Docker 镜像本质上就是一个把“所有运行依赖”都打包好的软件源，它规避了系统源版本不匹配的问题，在离线环境里特别实用。唯一的门槛是目标机器需要先有 Docker 环境，否则这个方案也走不通。

如果整个内网有成百上千台机器要装软件，拷贝镜像的玩法就不够看了，正规做法是在内网搭一个软件源镜像，比如用 aptly 同步麒麟仓库，或者用 devpi 同步 Python 包。所有内网机器把源地址指向内网服务器，这在生产环境里是更可维护的方案，也是“换源”思路的进阶形态。

5. 换源后常见问题排查与避坑清单

5.1 高频报错速查表

换源后遇到的报错五花八门，但大多数都能归到下面几类，整理成表方便对照：

报错信息	常见原因	处理办法
404 Not Found	源路径或发行版代号与系统版本不匹配	重新核对 V10 后面的 SP 版本，检查镜像站目录
NO_PUBKEY	仓库公钥未导入	用 apt-key/gpg 导入对应公钥
Hash Sum mismatch	镜像同步不完整或本地缓存损坏	`sudo apt clean`后重新 update，或换镜像站
Could not get lock /var/lib/dpkg/lock-frontend	有 apt/dpkg 进程正在运行	找到并结束占用进程，或重启后重试
Package has no installation candidate	软件源里没有该包，或组件未开启	检查是否启用了 universe/multiverse 组件
Conflicting distributions	sources.list 混合了不同版本	去除多余的源，只保留本版本对应的源
EXPKEYSIG 或过期签名	仓库公钥过期	重新获取该仓库的最新公钥导入

这些报错覆盖了换源后 90% 以上的异常，照着处理基本能解决。

5.2 几条踩过坑才懂的经验

最后分享几条我自己在实际操作中积累的经验。

第一，换源之后千万别急着执行apt full-upgrade，要先在apt upgrade前查看待升级的包列表。麒麟系统有些组件和桌面环境强绑定，无脑升级可能把桌面搞崩。我遇到过一台机器换完源后跑了 full-upgrade，重启后图形界面起不来，最后只能恢复快照，从那以后我再也不在麒麟系统上跑 full-upgrade 了。

第二，不要同时开几个镜像源反复横跳。不同镜像的同步进度不一样，某些仓库文件可能一个镜像已经更新了、另一个还没同步，这时候来回切源容易引发 Hash Sum mismatch。不如固定一个稳定的源，测试没问题后就一直用下去。

第三，遇到依赖错误不要想着重装系统，先执行下面的命令，大多数问题都能自动修复：