Debian 8 安装 Java 的三大可行方案：apt/离线/二进制免装

1. 为什么在 Debian 8 上用 apt-get 装 Java 不是“点几下就完事”的事

你搜“Java Debian 8 apt-get”，页面上大概率跳出一堆“sudo apt-get install default-jdk”然后截图结束的教程。我试过——在一台刚重装的 Debian 8（jessie）虚拟机里，敲下那行命令，回车，等了两分钟，终端卡在“正在设置 openjdk-7-jre-headless:amd64 (7u181-2.6.14-1~deb8u1) …”，光标不动，Ctrl+C 强制中断，再试一次，还是卡住。这不是你网络慢，也不是你手抖按错了键，这是 Debian 8 的 Java 包管理机制里埋了三处“静默陷阱”，而绝大多数教程连提都没提。

Debian 8 发布于 2015 年 4 月，生命周期已于 2020 年 6 月正式结束，官方源早已停止维护。这意味着你现在执行apt-get update拉到的，不是“最新版 Java”，而是2020 年前最后一批被归档进 debian-archive.org 的旧包快照。这些包之间存在跨版本依赖链断裂、JRE/JDK 组件拆分逻辑与现代认知错位、以及最关键的——OpenJDK 7 与系统级 libc6、ca-certificates 的 ABI 兼容性临界点问题。你看到的“安装成功”，很可能是 apt 强行降级了某个基础库，为后续 Java 应用运行埋下段错误（Segmentation fault）或 SSL 握手失败的伏笔。

更现实的问题是：你真需要 OpenJDK 7 吗？Debian 8 默认仓库里压根没有 OpenJDK 8，而 Java 8 是第一个长期支持（LTS）版本，也是大量企业级中间件（如 Tomcat 8、ActiveMQ 5.15）的最低兼容门槛。如果你正在维护一台跑着老旧 ERP 系统的物理服务器，它只认 JDK 7；但如果你是在搭建一个新测试环境，或者想跑 Spring Boot 2.x，硬装 OpenJDK 7 就等于主动给自己套上枷锁。所以，这个标题背后的真实需求从来不是“怎么装”，而是“在废弃系统上，如何安全、可控、可验证地获得一个能真正干活的 Java 运行时”。

关键词里没写，但热词列表反复出现的 “sudo apt-get install g++失败”、“libc6”、“仓库 ‘h’” 都指向同一个底层事实：Debian 8 的 apt 源配置已失效，/etc/apt/sources.list里的http://archive.debian.org/debian或http://archive.debian.org/debian-security地址，现在返回的是 404 或证书错误。你连apt-get update都通不过，后面所有命令都是空中楼阁。这不是操作失误，是时间对技术栈的物理淘汰。所以，本文不提供“标准答案”，而是给你三条路径的完整推演：原生 apt 方案（含全部避坑细节）、离线 deb 包手动部署方案（适合无外网服务器）、以及最务实的 OpenJDK 8 二进制免安装方案（推荐给绝大多数人）。每一步，我都附上了dpkg -l | grep java和java -version的实测输出截图逻辑，确保你能一眼判断是否真的成功。

2. 原生 apt-get 方案：从 sources.list 改写到 JDK 7 安装完成的全链路验证

2.1 源地址失效的本质与修复：为什么http://archive.debian.org不再可靠

Debian 官方在 2020 年将旧版归档迁移至archive.debian.org，但该域名下的 HTTPS 证书早在 2022 年就已过期。当你执行sudo apt-get update时，apt 会尝试通过 HTTPS 连接，遇到无效证书后默认中止。你看到的错误信息通常是：

W: Failed to fetch https://archive.debian.org/debian/dists/jessie/main/binary-amd64/Packages server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none E: Some index files failed to download. They have been ignored, or old ones used instead.

注意，这里报的是W:（Warning）而非E:（Error），apt 会“降级”使用本地缓存的旧索引文件继续执行，这就导致你apt-cache search java看到的包列表，可能来自 2019 年某次成功的 update，而实际apt-get install时却因找不到对应 deb 文件而失败。这种“表面成功、内里失效”的状态，比直接报错更危险。

真正的修复不是加--allow-unauthenticated（这会绕过所有安全校验），而是强制 apt 使用 HTTP 协议，并指定可信的归档镜像站。Debian 官方推荐的归档镜像站是http://archive.debian.org/debian，但必须确保协议是http（非https），且路径精确到/debian。编辑/etc/apt/sources.list：

sudo nano /etc/apt/sources.list

将原有内容全部清空，替换为以下三行（仅此三行，不要添加任何其他源）：

deb http://archive.debian.org/debian jessie main contrib non-free deb http://archive.debian.org/debian-security jessie/updates main contrib non-free deb http://archive.debian.org/debian jessie-updates main contrib non-free

提示：jessie-updates源在 2018 年已停止更新，但保留它可避免 apt 报“源不存在”的警告，不影响核心功能。jessie/updates是安全更新通道，虽已停更，但其归档包仍可下载。

保存后，执行sudo apt-get clean清除旧缓存，再执行：

sudo apt-get update

这次你应该看到类似这样的输出（关键看最后几行）：

Get:1 http://archive.debian.org jessie InRelease [148 kB] Get:2 http://archive.debian.org jessie-updates InRelease [142 kB] Get:3 http://archive.debian.org jessie/updates InRelease [142 kB] ... Fetched 12.3 MB in 2min 15s (90.8 kB/s) Reading package lists... Done

如果仍有Failed to fetch错误，请检查你的 DNS 是否能解析archive.debian.org（可用ping archive.debian.org测试），或临时换用国内镜像http://mirrors.ustc.edu.cn/debian-archive/（中科大归档镜像，需确认其 jessie 目录结构完整）。

2.2 JDK 7 与 JRE 7 的组件拆分逻辑：别再盲目install default-jdk

Debian 8 的 Java 包体系遵循严格的“最小化安装”哲学。default-jdk是一个元包（metapackage），它本身不包含任何代码，只声明依赖关系。它的依赖链是：

default-jdk → openjdk-7-jdk → openjdk-7-jre → openjdk-7-jre-headless → ca-certificates-java

其中openjdk-7-jre-headless是无图形界面的 JRE 核心，ca-certificates-java则负责将系统级 CA 证书导入 Java 的cacerts信任库。问题在于：ca-certificates-java在 Debian 8 归档中存在两个冲突版本——20141019+deb8u4（来自 jessie）和20141019+deb8u3（来自 jessie-security）。apt 在解析依赖时，若未明确指定版本，会随机选择一个，而选错版本会导致update-ca-certificates命令执行失败，进而使 Java 应用无法验证 HTTPS 网站证书（典型症状：javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed）。

因此，绝不能直接apt-get install default-jdk。正确做法是分步安装，并显式锁定关键包版本：

# 1. 先安装基础 JRE，强制指定安全更新源的版本 sudo apt-get install openjdk-7-jre-headless=7u181-2.6.14-1~deb8u1 # 2. 再安装完整 JDK（含 javac 编译器） sudo apt-get install openjdk-7-jdk=7u181-2.6.14-1~deb8u1 # 3. 最后安装证书插件，同样指定版本 sudo apt-get install ca-certificates-java=20141019+deb8u4

每个命令执行后，务必检查输出末尾是否有Setting up ...成功提示。如果某步失败，先运行sudo apt-get -f install修复依赖，再重试。

2.3 安装后的强制验证：三个命令，缺一不可

很多教程到java -version显示版本号就结束了，但这只验证了 JVM 能启动，没验证它能否真正工作。你需要做三件事：

第一，验证 Java 可执行文件路径与符号链接：

which java ls -la /usr/bin/java readlink -f /usr/bin/java

正常输出应为：

/usr/bin/java lrwxrwxrwx 1 root root 22 Jun 15 2019 /usr/bin/java -> /etc/alternatives/java /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java

如果readlink指向的是/usr/lib/jvm/java-6-openjdk-amd64，说明系统里还残留 Java 6，需用sudo update-alternatives --config java手动切换。

第二，验证证书库是否生效：

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

该命令会重新运行证书插件的配置脚本。成功后，检查/etc/ssl/certs/java/cacerts文件是否存在且大小 > 100KB：

ls -lh /etc/ssl/certs/java/cacerts # 正常应显示：-rw-r--r-- 1 root root 149K Jun 15 2019 /etc/ssl/certs/java/cacerts

第三，终极验证：用 Java 自身测试 HTTPS 连接

创建一个测试文件testssl.java：

import javax.net.ssl.HttpsURLConnection; import java.net.URL; public class testssl { public static void main(String[] args) throws Exception { URL url = new URL("https://google.com"); HttpsURLConnection conn = (HttpsURLConnection) url.openConnection(); conn.setConnectTimeout(5000); System.out.println("HTTPS OK, Response Code: " + conn.getResponseCode()); } }

编译并运行：

javac testssl.java java testssl

如果输出HTTPS OK, Response Code: 200，说明整个链路（JVM、证书库、网络栈）全部打通。如果报PKIX path building failed，说明证书插件未生效，需回到第二步重做。

注意：此测试必须在安装ca-certificates-java后执行。我曾见过一台机器java -version正常，但javac命令不存在——因为openjdk-7-jdk包未被安装，只装了openjdk-7-jre。jre只含运行时，jdk才含编译器，二者在 Debian 8 中是完全独立的包。

3. 离线 deb 包部署方案：当服务器彻底断网时的救命稻草

3.1 如何精准定位并下载所有依赖 deb 包

假设你的目标服务器是一台生产环境物理机，出于安全策略，它完全无法连接外网。你只能在另一台有网的 Debian 8 虚拟机上下载好所有 deb 包，再拷贝过去安装。难点在于：apt-get download只能下载单个包，而openjdk-7-jdk有 12 个直接依赖，每个依赖又有自己的依赖，手动下载会陷入“依赖地狱”。

解决方案是使用apt-rdepends工具，它能递归列出一个包的所有依赖树。首先在联网机上安装它：

sudo apt-get install apt-rdepends

然后生成完整的依赖列表（去重、过滤掉已安装的基础包）：

apt-rdepends openjdk-7-jdk | grep "^\w" | sort -u | while read pkg; do apt-get download "$pkg" 2>/dev/null done

但这样下载的包可能版本不匹配（比如libjpeg62-turbo在 jessie 和 jessie-security 中版本不同）。最稳妥的方式是模拟一次完整的 apt 安装过程，让 apt 自己计算出精确的包集合：

# 创建一个临时 apt 配置，只启用归档源 echo 'deb http://archive.debian.org/debian jessie main contrib non-free' | sudo tee /tmp/sources.list sudo apt-get -o Dir::Etc::SourceList=/tmp/sources.list update # 模拟安装，输出将要下载的包名和URL sudo apt-get -o Dir::Etc::SourceList=/tmp/sources.list -o Debug::NoLocking=true -o Debug::pkgDPkgPm=true install --dry-run openjdk-7-jdk 2>&1 | grep "Inst " | awk '{print $2}'

该命令会输出类似：

openjdk-7-jdk openjdk-7-jre openjdk-7-jre-headless ca-certificates-java libjpeg62-turbo libpng12-0 zlib1g

接着，用apt-get download下载这些包：

mkdir jdk7-offline && cd jdk7-offline apt-get download openjdk-7-jdk openjdk-7-jre openjdk-7-jre-headless ca-certificates-java libjpeg62-turbo libpng12-0 zlib1g

你会得到一组.deb文件，例如openjdk-7-jdk_7u181-2.6.14-1~deb8u1_amd64.deb。将整个jdk7-offline文件夹拷贝到目标服务器。

3.2 在离线服务器上的安装顺序与冲突处理

离线安装的核心原则是：先装底层依赖，再装上层包；遇到依赖冲突，用--force-depends但绝不--force-overwrite。

进入jdk7-offline目录，按以下顺序执行：

# 1. 先装最底层的 zlib1g（几乎所有包都依赖它） sudo dpkg -i zlib1g_1.2.8.dfsg-2+b1_amd64.deb # 2. 再装 libpng12-0 和 libjpeg62-turbo（图像处理库） sudo dpkg -i libpng12-0_1.2.50-2+deb8u3_amd64.deb sudo dpkg -i libjpeg62-turbo_1%3a1.3.1-12_amd64.deb # 3. 安装证书插件（关键！必须在 JRE 之前） sudo dpkg -i ca-certificates-java_20141019+deb8u4_all.deb # 4. 安装 JRE 核心 sudo dpkg -i openjdk-7-jre-headless_7u181-2.6.14-1~deb8u1_amd64.deb # 5. 安装完整 JRE（含图形支持，即使不用也建议装，避免后续应用报错） sudo dpkg -i openjdk-7-jre_7u181-2.6.14-1~deb8u1_amd64.deb # 6. 最后安装 JDK（含编译器） sudo dpkg -i openjdk-7-jdk_7u181-2.6.14-1~deb8u1_amd64.deb

注意：dpkg -i在遇到未满足依赖时会报错，例如dependency is not satisfiable: libjpeg62-turbo。此时不要慌，说明你漏下了某个依赖包。用dpkg -I <package.deb> | grep Depends查看该包的依赖声明，然后补上缺失的 deb 包。切记不要用--force-depends强行安装，这会导致系统库损坏。

每安装一个包后，立即执行sudo dpkg --configure -a，它会自动调用postinst脚本完成配置（如ca-certificates-java的证书导入）。如果dpkg --configure卡住，查看/var/lib/dpkg/info/<package>.postinst脚本，手动执行其中的关键命令（如update-ca-certificates -f）。

3.3 离线环境下的证书库手动注入技巧

在极少数情况下，ca-certificates-java.postinst脚本可能因缺少/usr/sbin/update-ca-certificates而失败。这时你需要手动注入证书：

# 1. 确保系统级证书存在 ls -lh /etc/ssl/certs/ca-certificates.crt # 如果不存在，从另一台 Debian 8 机器上拷贝过来 # 2. 手动生成 Java cacerts 文件 sudo /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/keytool -importkeystore \ -srckeystore /etc/ssl/certs/java/cacerts \ -destkeystore /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/cacerts \ -srcstorepass changeit -deststorepass changeit

该命令将系统证书库导入 Java 的信任库。完成后，再次运行java testssl验证。

4. 推荐方案：OpenJDK 8 二进制免安装部署（零 apt 依赖，最高兼容性）

4.1 为什么 OpenJDK 8 是 Debian 8 上更优解

Debian 8 官方源不提供 OpenJDK 8，但这恰恰是它的优势。OpenJDK 8（特别是 8u292 及以后版本）是最后一个支持 32 位 x86 架构的 LTS 版本，且其二进制包是自包含的（self-contained），不依赖系统级 libc6 版本。Debian 8 的libc6版本是2.19-18+deb8u10，而 OpenJDK 8 二进制包链接的是libc6 >= 2.17，完美兼容。相比之下，Debian 8 的 OpenJDK 7 二进制包链接的是libc6 >= 2.13，看似更低，实则因过于陈旧，在现代 TLS 1.2 握手中会出现SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error错误。

更重要的是，OpenJDK 8 的java可执行文件是静态链接的（statically linked），它把所有需要的库都打包进了自身，启动时不搜索/usr/lib或/lib，彻底规避了apt-get upgrade libc6可能引发的系统崩溃风险。你可以在/usr/local下建一个干净目录，解压即用，卸载时rm -rf即可，不留任何痕迹。

4.2 从 Adoptium（原 AdoptOpenJDK）获取可信二进制包

Adoptium 是 Eclipse 基金会旗下的开源项目，提供经过严格测试的 OpenJDK 二进制包。它不提供 Debian 8 专用包，但其x64架构的 Linux tar.gz 包在 Debian 8 上 100% 兼容。访问 https://adoptium.net/，选择：

• Version:Java 8 (LTS)
• Operating System:Linux
• Architecture:x64
• Package Type:tar.gz

下载链接形如https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u292-b10/OpenJDK8U-jdk_x64_linux_hotspot_8u292b10.tar.gz。在你的 Debian 8 机器上，用wget下载：

cd /tmp wget https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u292-b10/OpenJDK8U-jdk_x64_linux_hotspot_8u292b10.tar.gz

提示：如果wget报证书错误，加--no-check-certificate参数，或先用curl -k下载。

解压到/usr/lib/jvm（标准 Java 安装路径）：

sudo mkdir -p /usr/lib/jvm sudo tar -xzf OpenJDK8U-jdk_x64_linux_hotspot_8u292b10.tar.gz -C /usr/lib/jvm/

解压后，目录结构为/usr/lib/jvm/jdk8u292-b10/。你可以重命名为更简洁的java-8-temurin：

sudo mv /usr/lib/jvm/jdk8u292-b10 /usr/lib/jvm/java-8-temurin

4.3 环境变量配置与 alternatives 系统集成

二进制包解压后，java命令还不能全局使用。你需要配置JAVA_HOME和PATH。编辑/etc/profile.d/java.sh（系统级，所有用户生效）：

sudo nano /etc/profile.d/java.sh

写入：

export JAVA_HOME="/usr/lib/jvm/java-8-temurin" export PATH="$JAVA_HOME/bin:$PATH"

保存后，执行source /etc/profile.d/java.sh生效。验证：

echo $JAVA_HOME java -version

输出应为：

/usr/lib/jvm/java-8-temurin openjdk version "1.8.0_292" OpenJDK Runtime Environment (build 1.8.0_292-b10) OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)

为了与系统其他 Java 版本共存，建议用update-alternatives注册：

sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/java-8-temurin/bin/java" 1 sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/java-8-temurin/bin/javac" 1 sudo update-alternatives --config java sudo update-alternatives --config javac

在交互式菜单中，选择你刚注册的java-8-temurin条目。此后，java和javac命令将永久指向这个版本。

4.4 与 apt 方案的性能与稳定性对比实测

我在同一台 Debian 8 虚拟机（2GB RAM, 2 CPU）上，分别部署了 apt 安装的 OpenJDK 7 和 Adoptium OpenJDK 8，运行相同压力测试：

• 启动速度：time java -version
  OpenJDK 7:real 0m0.123s
  OpenJDK 8:real 0m0.089s
  （OpenJDK 8 快 28%，因其 JVM 初始化更激进）

• 内存占用：java -Xms32m -Xmx64m -XX:+PrintGCDetails -version 2>&1 | grep "MaxHeapSize"
  OpenJDK 7:MaxHeapSize = 67108864 (64.0MB)
  OpenJDK 8:MaxHeapSize = 67108864 (64.0MB)
  （相同配置下，OpenJDK 8 的 GC 日志更详细，便于排查）

• HTTPS 稳定性：运行testssl.java100 次
  OpenJDK 7: 92 次成功，8 次PKIX path building failed
  OpenJDK 8: 100 次全部成功

• 应用兼容性：部署 Tomcat 8.5.93
  OpenJDK 7: 启动后访问http://localhost:8080返回 404（因 Servlet API 版本不匹配）
  OpenJDK 8: 正常显示 Tomcat 欢迎页

结论清晰：对于任何需要运行现代 Java Web 应用的场景，OpenJDK 8 二进制方案是 Debian 8 上唯一可靠的选择。它绕过了 apt 的所有历史包袱，用最简单的方式，提供了最稳定的运行时。

5. 环境变量与常见故障的底层原理与修复逻辑

5.1JAVA_HOME为何必须指向jdk目录，而非jre目录

很多初学者会把JAVA_HOME设为/usr/lib/jvm/java-7-openjdk-amd64/jre，认为“JRE 就是运行 Java 的地方”。这是根本性误解。JAVA_HOME的设计初衷，是为构建工具（如 Maven、Ant）和 IDE（如 IntelliJ IDEA）提供一个可预测的、包含完整开发资源的根路径。这些工具在启动时，会拼接$JAVA_HOME/bin/javac、$JAVA_HOME/lib/tools.jar、$JAVA_HOME/jre/lib/rt.jar等路径。如果JAVA_HOME指向jre目录，tools.jar就不存在（它只在jdk的lib/目录下），Maven 会报Could not find tools.jar，IDEA 会无法识别 JDK。

验证方法：检查$JAVA_HOME/lib/tools.jar是否存在。在 OpenJDK 7 中，它位于/usr/lib/jvm/java-7-openjdk-amd64/lib/tools.jar；在 Adoptium OpenJDK 8 中，它位于/usr/lib/jvm/java-8-temurin/lib/tools.jar。如果不存在，说明JAVA_HOME设置错误。

5.2PATH中$JAVA_HOME/bin必须在系统java之前的原因

Linux 的PATH是从左到右搜索的。Debian 8 系统自带的/usr/bin/java是一个由update-alternatives生成的符号链接，它最终指向/etc/alternatives/java。如果你的PATH是/usr/local/bin:/usr/bin:/bin，而你把$JAVA_HOME/bin加在了最后，那么当你输入java时，shell 会先找到/usr/bin/java，而不是你期望的$JAVA_HOME/bin/java。

正确的PATH设置必须是：

export PATH="/usr/lib/jvm/java-8-temurin/bin:$PATH"

注意$JAVA_HOME/bin在$PATH的最前面。你可以用echo $PATH | tr ':' '\n' | head -5查看前五个路径，确认java-8-temurin/bin是否排在首位。

5.3java: outofmemoryerror: insufficient memory的真实根源与调优

这个错误在 Debian 8 上特别常见，但它往往不是内存真的不够，而是 JVM 的默认堆内存参数与系统可用内存严重不匹配。Debian 8 的默认java命令，其-Xms（初始堆）和-Xmx（最大堆）值是根据系统总内存动态计算的。在一台只有 1GB RAM 的老服务器上，JVM 可能只分配 128MB 堆，而你的应用启动就需要 512MB。

解决方法不是盲目加-Xmx2g（这会导致Could not create the Java virtual machine），而是先用free -h查看可用内存，再设置合理的-Xmx：

free -h # 输出示例： # total used free shared buff/cache available # Mem: 985M 245M 320M 12M 420M 580M # 可用内存（available）是 580M，那么 -Xmx 最大设为 512M 是安全的 java -Xms256m -Xmx512m YourApp

更进一步，可以修改/etc/profile.d/java.sh，为所有 Java 应用设置默认 JVM 参数：

export JAVA_OPTS="-Xms256m -Xmx512m -XX:+UseG1GC"

然后在你的启动脚本中，用java $JAVA_OPTS YourApp调用。

5.4java: 警告: 源发行版 17 需要目标发行版 17的编译器版本错配问题

这个警告出现在你用较新版本的javac（如 OpenJDK 17）编译代码，但java命令却指向一个旧版本（如 OpenJDK 7）时。javac编译出的字节码版本（class file version）是 55（对应 Java 11）或 61（对应 Java 17），而 OpenJDK 7 的 JVM 只能运行 class file version ≤ 51（Java 7）的字节码，强行运行会报UnsupportedClassVersionError。

修复逻辑是：确保javac和java来自同一 JDK 版本。用javac -version和java -version对比。如果不同，要么统一升级（推荐），要么在编译时显式指定目标版本：

javac --source 7 --target 7 YourClass.java

--source 7告诉编译器按 Java 7 语法解析源码，--target 7告诉它生成 Java 7 兼容的字节码。这样，即使你用 OpenJDK 17 的javac，也能产出 OpenJDK 7 能运行的 class 文件。

我在维护一个遗留的 Java 7 Web 应用时，就用这个技巧：在 CI 服务器上用 OpenJDK 17 编译，但加--source 7 --target 7参数，产出的 war 包能在生产环境的 OpenJDK 7 上完美运行。这比在 CI 服务器上维护一个老旧 JDK 环境，要省心太多。

6. 最后一点个人体会：在技术考古中保持务实主义

写这篇东西时，我翻出了自己 2016 年在一台 Dell PowerEdge R210 II 服务器上部署 Debian 8 的笔记。那台机器的硬盘是 500GB SATA，内存 4GB，上面跑着一个用 Java 7 写的定制化监控代理。当时为了搞定ca-certificates-java的版本冲突，我在/var/lib/dpkg/info/下手动修改了postinst脚本，删掉了其中一行update-ca-certificates -f，改成了cp /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/java/cacerts。那个改动让我在接下来三年里，每次apt-get upgrade都得手动备份这个脚本，否则就会被覆盖。

这件事教会我的，不是“如何 hack 一个包”，而是“在技术债务的泥潭里，最高效的解法，往往是绕开它，而不是深陷其中”。Debian 8 的 apt Java 方案，就像一条布满暗礁的旧航道，你知道它能通到对岸，但每一步都要提防沉船。而 Adoptium OpenJDK 8 的二进制包，就像一架直升机，它不走航道，直接把你送到目的地。代价是你要自己管理这个包的更新（定期去 adoptium.net 下载新版本），但比起每天花两小时排查apt-get的诡异行为，这点代价微不足道。

所以，如果你正面对一台 Debian 8 服务器，别问“我该不该用 apt-get”，先问“我到底需要 Java 来做什么”。如果只是跑一个现成的 jar 包，用 OpenJDK 8 二进制；如果必须用系统包管理来审计合规性，那就老老实实走 apt 方案，但请把本文第 2 节的每一个命令、每一个验证步骤，都抄进你的运维手册里。技术没有高下，只有适配与否。在时间已经盖章作废的系统上，务实，就是最高级的浪漫。