在 Ubuntu 18.04 上装 R，最让人头大的往往不是 R 本身，而是 apt 的各种“倔脾气”。我遇到过一台机器，执行sudo apt install r-base时，先是卡在无法连接上 dl.google.com:80 (6.6.6.6)，连接超时，好不容易跳过这个坑，又弹出一个E: 无法修正错误，因为您要求某些软件包保持现状，就是它们破坏了软件包间的依赖关系。说实话，这两个报错在 18.04 上非常典型，经常一起出现，本质上是“软件源污染 + 依赖关系破损”。这篇文章就把整个排查和修复过程完整记录下来，希望帮到同样被这两个报错卡住的人。
我自己是从 Ubuntu 16.04 一路用到 18.04 的，R 语言在数据分析、统计建模和画图方面都离不开，服务器上必须装得干净利落。但 apt 这个老伙计一旦“闹情绪”，就是连环坑。下面我用实际踩坑的顺序来写，尽量避免你重复走弯路。
1. 问题场景与成因定位
1.1 安装 R 时的典型报错现场
大部分人在终端里运行的是这样的命令：
sudo apt install r-base r-base-dev然后屏幕开始滚动，没想到过了几秒就卡住了，输出类似：
Err:1 http://dl.google.com/linux/chrome/deb stable InRelease 无法连接上 dl.google.com:80 (6.6.6.6)，连接超时紧接着后面跟着警告，apt 的索引更新失败。如果你看不到具体报错，只看到“连接超时”，大概率是某个第三方源出了问题。更烦人的是，apt update 失败之后，你再次执行 install，又会出现：
E: 无法修正错误，因为您要求某些软件包保持现状，就是它们破坏了软件包间的依赖关系。两个问题叠加，看起来像是 R 本身装不上，但只要冷静分析就会发现，第一个报错是“环境病”，第二个报错是“依赖伤”，两者虽然独立，却经常手拉手出现。这里我先说结论：先治病灶，再处理依赖，顺序不能乱。
1.2 为什么 apt 会去访问 dl.google.com
很多人在第一次看到dl.google.com时都会愣一下：我明明是在装 R，跟 Google 有什么关系？其实这是 Ubuntu 软件源的“历史遗留”问题。apt 在sudo apt update时，会扫描/etc/apt/sources.list和/etc/apt/sources.list.d/下所有.list文件。只要某台机器之前装过 Google Chrome、Google Earth 或者 Google Cloud SDK，就会留下一个类似google-chrome.list的文件，指向http://dl.google.com/linux/chrome/deb/。
当你的网络环境访问不到 Google 域名时，这个源就成了“坏源”。apt 更新主索引时碰到它就会超时，导致整个 apt 仓库状态不一致。这是为什么你安装 R 时会牵扯出 Google 服务器。其实安装 R 本身并不需要 Google 的任何东西，只要确认系统里没有必须依赖 Chrome 的需求，把这个坏源移除掉就行。
顺便说一句，6.6.6.6这种 IP 是 DNS 解析异常或本地 hosts 文件问题导致的结果，不是真实 IP。你可以检查一下/etc/hosts或/etc/resolv.conf，但更省事的办法是直接绕过这个源。
1.3 依赖关系错误的根本原因
第二个报错“要求某些软件包保持现状，就是它们破坏了软件包间的依赖关系”，在 apt 术语里其实是说：当前系统的软件包版本之间出现了依赖冲突，但 apt 默认不会擅自升级或降级某些包来满足条件。
举个例子，你系统里已经有一个老版本的libcurl4，而新安装的 R 包依赖libcurl4-openssl-dev，它需要对应版本的libcurl4。apt 检测到版本不匹配，如果升级libcurl4可能会影响其他软件，此时 apt 会保守地选择“保持现状”，把问题抛给你。这种错误在 Ubuntu 18.04 上尤其常见，因为 Bionic 的官方源版本较老，而 CRAN 或第三方源里的 R 包又比较新，双方很容易发生版本不匹配。
另外，如果之前系统里残留了i386架构的包，或者有过未完成的安装（比如中断的dpkg），也会加剧依赖问题。所以，处理时要先检查dpkg状态，再做修复。
2. 第一步：搞定 dl.google.com 连接超时
2.1 检查源列表：谁在引用 dl.google.com
在动手之前，先把“幕后黑手”找出来。用这个命令查看所有 apt 源里哪些文件包含dl.google.com：
grep -r "dl.google.com" /etc/apt/sources.list /etc/apt/sources.list.d/正常情况下，你会看到类似输出：
/etc/apt/sources.list.d/google-chrome.list:deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main这就说明机器上确实配置了 Google Chrome 的源。如果输出为空，那可能需要检查apt的配置或代理变量。
还有一种情况是，部分 R 相关的第三方 PPA 会间接依赖 Google 的库（比如某些编译好的二进制包），但这种情况很少。最常见的还是 Chrome 或 Google Earth 的源残留。
2.2 临时禁用非必要源（或备份移除）
找到源文件之后，不要直接rm -rf，先备份，毕竟以后可能要恢复。更稳妥的做法是给文件改名，让 apt 忽略它：
sudo cp /etc/apt/sources.list.d/google-chrome.list /etc/apt/sources.list.d/google-chrome.list.bak sudo rm /etc/apt/sources.list.d/google-chrome.list如果你不想删除，也可以直接注释掉源文件里的deb行，效果一样。这里我的建议是：如果机器上并没有使用 Chrome 的需求，直接移除；如果以后要装 Chrome，也可以从官网下载离线 deb 包，不一定非得使用这个源。
同时，建议把所有第三方源都整理一遍，尤其是里面包含dl.google.com、以及一些不常用的 PPA，统统先备份后移除，免得后续 update 又碰到其他坏源。
2.3 正确配置 CRAN 源（清华/阿里镜像）
接下来要添加 R 官方的 CRAN 源。因为原版的cloud.r-project.org在某些网络环境下也可能连接不稳定，所以我更推荐用国内镜像源。以清华镜像为例，Ubuntu 18.04 对应的代号是 bionic，R 4.0 及以上版本使用bionic-cran40/目录。
先导入 CRAN 的 GPG 公钥：
wget -qO- https://mirrors.tuna.tsinghua.edu.cn/CRAN/bin/linux/ubuntu/marutter_pubkey.asc | sudo tee /etc/apt/trusted.gpg.d/cran_ubuntu_key.asc然后写入源列表：
echo "deb https://mirrors.tuna.tsinghua.edu.cn/CRAN/bin/linux/ubuntu bionic-cran40/" | sudo tee /etc/apt/sources.list.d/r-cran.list执行更新：
sudo apt update如果前面移除坏源的操作到位，这次 update 应该能顺利完成，不会再有dl.google.com超时的报错。
2.4 安装 R 与验证
源疏通之后，就可以正式安装 R 了：
sudo apt install r-base r-base-devr-base是运行环境，r-base-dev包含了编译 R 扩展包需要的开发工具和头文件，强烈建议一起装。安装完成后，用R --version验证：
R --version如果看到R version 4.x.x，说明基本环境已经通了。我自己装完之后还会顺手跑一个最简单的命令：
Rscript -e 'cat("R works!\n")'能输出R works!就说明环境没问题。
3. 第二步：解决依赖关系“保持现状”错误
3.1 先做一次自动修复：--fix-broken
如果你已经走到apt update成功了，但安装 R 仍然报依赖错误，说明不是网络源的问题，而是系统软件包确实有冲突。这时不要慌，先让 apt 自己试着修复：
sudo apt --fix-broken install这个命令会检查系统中处于“unpacked”或“half-configured”状态的包，并尝试安装缺失的依赖。如果它自动解决问题，那你运气不错，再执行sudo apt install r-base应该就能过。不少时候这个命令会输出“正在修正依赖关系”并自动装一堆东西，静静等它跑完就行。
3.2 借助 aptitude 的智能依赖解算
如果--fix-broken没能解决，或者报错信息特别复杂，我强烈推荐使用aptitude。它比apt更擅长处理依赖冲突，因为它会给出多种解决方案，让你选择保留还是降级。
先把 aptitude 装上：
sudo apt install aptitude然后用它安装 R：
sudo aptitude install r-base这时候 aptitude 会列出冲突的包，并给出类似这样的选项：
- 保持某些包的现有版本
- 降低某个包的版本
- 升级其他包
我曾经遇到一台机器上libssl1.1和libssl-dev版本对不上，aptitude 提示可以把libssl1.1降级到某个旧版本。我选择了“是”，然后再安装 R 就成功了。注意，aptitude 的交互界面里，键盘Y表示接受建议，n表示拒绝，有时候要试几次才能找到合适的解。
3.3 手动降级/升级冲突包
如果 aptitude 给出的方案你还不满意，或者根本不给方案，那就需要手动查看冲突包的具体版本。先找到报错信息里的包名，比如：
r-base-core : 依赖: libcurl4-openssl-dev (>= 7.28.0) 但是它将不会被安装然后查看当前版本和可用版本：
apt-cache policy libcurl4-openssl-dev libcurl4输出结果里会显示 “已安装：(none)” 或 “候选：xxx”。如果候选版本不满足 R 的依赖，可能需要先升级系统软件源缓存，或者从其他可靠渠道把源版本更新。另一个技巧是手动安装低一层依赖，比如：
sudo apt install libcurl4=7.58.0-2ubuntu3.24注意版本号要以apt-cache policy实际显示的可安装版本为准。这种手动锁定版本的做法，在 Ubuntu 18.04 上很常用，但一定要记得不要乱动libc6这类核心库，否则系统会崩。
3.4 彻底重装 R 相关包（干净环境）
如果以上方法都失败了，可能是之前安装 R 的残留包和现有系统搅在一起。这时候我建议把 R 相关的包全部清掉，重新来一遍：
sudo apt purge r-base r-base-dev r-base-core r-recommended sudo apt autoremove然后重新更新并安装：
sudo apt update sudo apt install r-base r-base-dev注意purge会删除配置文件，如果你有自定义的.Rprofile，记得先备份。一般来说，到了这一步，顽固的依赖问题都能解决。要是还残留问题，那就得考虑是不是系统源本身太旧，也许需要手动升级一些基础库。
4. 实操过程与完整脚本记录
4.1 一份可直接运行的修复流程
这里我把前面讲的操作整合成一个完整的终端流程，方便你直接复制执行。建议逐行执行，不要整段一把梭，至少每段停下来看一眼输出，避免误删重要文件。
# 1. 备份原有 apt 源 sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo mkdir -p /etc/apt/sources.list.d.bak sudo cp /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d.bak/ 2>/dev/null # 2. 查找并禁用引用 dl.google.com 的源 grep -rl "dl.google.com" /etc/apt/sources.list /etc/apt/sources.list.d/ sudo sed -i 's/^deb /# deb /' /etc/apt/sources.list.d/google-chrome.list # 3. 替换主源为清华镜像（可选但推荐） sudo sed -i 's/archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list sudo sed -i 's/security.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list # 4. 添加 CRAN 清华镜像源 wget -qO- https://mirrors.tuna.tsinghua.edu.cn/CRAN/bin/linux/ubuntu/marutter_pubkey.asc | sudo tee /etc/apt/trusted.gpg.d/cran_ubuntu_key.asc echo "deb https://mirrors.tuna.tsinghua.edu.cn/CRAN/bin/linux/ubuntu bionic-cran40/" | sudo tee /etc/apt/sources.list.d/r-cran.list # 5. 更新索引并修复依赖 sudo apt update sudo apt --fix-broken install -y # 6. 安装 R sudo apt install r-base r-base-dev -y这段流程是我在实际服务器和虚拟机上都跑过的组合拳，能覆盖 80% 的安装失败场景。剩下 20% 的情况下，可能会卡在某个具体依赖包上，那就继续看 5.2 和 5.3。
4.2 关键命令逐行解释
为什么先备份？因为sed -i和rm都不可逆，一旦改错源文件，apt 可能彻底瘫痪。备份目录读取方便，后续要恢复直接cp回去就行。
为什么禁用而不是删除google-chrome.list？因为如果你的确需要 Chrome，以后还可以恢复。但如果你确定不需要，最后也可以彻底删除。用sed -i 's/^deb /# deb /'注释掉deb行，比直接删文件更安全。
为什么要把主源替换成清华镜像？因为 dl.google.com 超时只是表象，如果系统主源archive.ubuntu.com在国内也慢，apt update 一样会卡。替换成国内镜像后，下载包的速度会明显提升。这里我只处理了 Ubuntu 官方源，没有动ppa或cloud.r-project.org，如果需要，也可以将 Cloud 的源替换。
添加 CRAN 源时，公钥处理用的是tee到trusted.gpg.d，这是新版 apt 推荐的做法，比apt-key add更干净，不会污染全局 keyring。公钥地址是清华镜像直接提供的，与 CRAN 官方公钥一致，可以放心添加。
最后那步apt --fix-broken install -y很关键，它可以在安装真正开始前，把系统里残留的 dpkg 状态修正过来，避免安装 r-base 时半路中断。
4.3 安装后快速检查 R 语言环境
装完别急着关终端，先做几个简单测试，确认 R 真的能用。
检查版本：
R --version检查 R 是否能从 CRAN 安装包（注意指定镜像）：
Rscript -e 'install.packages("data.table", repos="https://mirrors.tuna.tsinghua.edu.cn/CRAN/")'如果你是从终端启动交互式 R，也可以直接输入：
install.packages("data.table")然后选择清华镜像或阿里镜像，通常国内都有镜像源。
另外还要检查一下 R 是否能编译包，因为很多 R 包需要本地编译，没有gcc和make会报错。r-base-dev已经帮你安装了这些依赖，所以你可以再验证：
Rscript -e 'library(data.table); data.table::rnorm(3)'能正常输出三个随机的正态分布数，说明安装完全可用。
5. 常见问题与避坑指南
5.1 “连接超时”但能 ping 通，怎么办
有些环境下，你ping dl.google.com能通，但 apt 执行时依然超时。这种情况多半是 apt 走了代理但代理没配好，或者网络里对 HTTP 请求有限制。可以检查一下系统变量：
env | grep -i proxy如果你在企业内网，需要走 HTTP 代理，可以在/etc/apt/apt.conf.d/下新增一个代理配置文件：
Acquire::http::Proxy "http://你的代理地址:端口"; Acquire::https::Proxy "http://你的代理地址:端口";但如果你只是个人电脑，并不需要代理，那就不要配这个。更常见的原因是 hosts 文件里写错了dl.google.com的 IP，导致连接到一个洋 IP。可以用getent hosts dl.google.com查看解析结果，如果显示的是奇怪的 IP（比如标题里的6.6.6.6），清理一下/etc/hosts里的相关行即可。
5.2 依赖错误中包名带 “-dev” 的特殊处理
R 包安装时，经常需要一堆-dev系统库，比如：
libcurl4-openssl-devlibssl-devlibxml2-dev
如果在安装 R 时，apt 报错说某个-dev包将被保持现状，大概率是因为系统中已经存在另一个同名但不同版本的开发库。比如你系统装了libcurl4-openssl-dev的某个老版本，而 R 需要新版本，apt 因为担心影响其它软件，就卡住不动。
这时候可以用：
sudo apt install libcurl4-openssl-dev --allow-change-held-packages或者先手动移除旧的开发包再装新版本。但注意，移除-dev包可能会连带删除一些编译工具，谨慎操作。稳妥起见，还是用 aptitude 检查依赖关系，让它给你一个最佳方案。
5.3 使用 Docker 隔离环境作为备选方案
如果你实在不想折腾宿主机，或者说宿主机里有太多生产依赖不能乱动，那我建议直接用 Docker 起一个干净的 Ubuntu 18.04 环境来装 R。这样所有的 apt 源、依赖冲突都被隔离在容器里，不会污染宿主机。
操作也不复杂：
docker run -it --name r-env ubuntu:18.04 bash进入容器后，先更新源，然后按照前面的步骤添加 CRAN 镜像并安装 R。容器里没有图形界面，但跑分析任务完全够用。宿主机和容器之间用docker cp拷贝数据，或者直接用-v挂载目录。
这个方法特别适合那种“我只需要在服务器上跑一次性 R 脚本”的场景。我自己维护的一些老旧任务，就直接把 R 环境打包成一个镜像，换机器也不愁。
5.4 小技巧：用国内镜像替换全部 apt 源
最后分享一个小技巧。如果你发现自己的系统默认源太慢，甚至经常超时，可以一键把主源替换成国内镜像。Ubuntu 18.04 默认源有两类域名，分别是archive.ubuntu.com和security.ubuntu.com，直接用 sed 替换：
sudo sed -i 's/archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list sudo sed -i 's/security.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list执行后再sudo apt update，速度会快很多。这个操作不会影响 R 安装，但能把整个系统的包管理器状态调整到最佳。如果你用的是阿里云机器，也可以换成mirrors.aliyun.com，原理一样。
我的习惯是：在 Ubuntu 18.04 上装 R 之前，永远先把源列表清理一遍。别小看这一步，很多“安装失败”其实都是源污染导致的连锁反应。等源干净了，依赖问题往往也能迎刃而解。
最后再多说一句：遇到E: 无法修正错误时，千万不要盲目执行apt remove卸载冲突包，更不要强制dpkg -i --force-all，否则系统可能会进入不可用的状态。先备份、再排查、后修复，才是稳妥的路子。这些经验都是我一次次重装系统换来的，写出来就是希望你能少踩几个坑。
