企业官网建设流程全解析

Ubuntu 14.04 上跑 PaddleOCR 的 PaddleHub Serving 服务部署，我前后折腾了将近两天，最后以彻底失败收场。这篇文章不打算教你怎么成功，而是想把这条走不通的路完整摊开：每一步的原始报错长什么样、我当时的判断是什么、哪个判断后来被证明是错的、四次绕路分别撞在哪堵墙上，以及最后我把服务挪去别处之后，这台老机器还剩什么用。如果你手里也有一台不能动系统的老服务器，或者正准备在一个"看起来还能跑"的环境里塞进一个新的推理服务，这篇失败记录大概率比一篇成功教程更能帮你省时间——因为它给你的是提前止损的依据，而不是事后复现的步骤。标题里那几个词，Ubuntu 14.04、PaddleOCR、PaddleHub Serving、服务部署、失败，每一个都对应着一个具体的决策点，我按时间顺序往下讲。

1. 一台还在跑 14.04 的机器，和我非要在这上面跑 OCR 的理由

1.1 现状盘点：这台机器到底有多"旧"

先把机器的底子说清楚，不然很多后面的结论看起来会像甩锅。这台机器是一个内网业务节点，uname -r出来是 3.13 系列内核，ldd --version是 2.19，系统自带的python3是 3.4.3，python指向 2.7.6，编译器是 4.8 那一代，libstdc++里能查到的GLIBCXX最高只到 3.4.19。系统本身的发行版支持周期早就结束了，官方源里的包基本停更，很多 newer 的轮子需要的基础库在这里根本不存在。

这台机器的定位其实很明确：跑一个老的、依赖固定的业务进程，稳定运行了好几年，动一次系统的风险远大于收益。所以我一开始就给自己定了一条红线：不升级发行版、不替换系统 Python、不动 glibc。后面所有的失败，本质上都是这条红线和我想要的软件之间的直接冲突。想清楚这一点很重要，因为很多人在这种场景下会陷入一种"再试一把也许就成了"的循环，而我这两天的教训是：当红线明确时，"能不能跑"这个问题应该在动手前就用版本矩阵回答掉，而不是靠 pip 报错来告诉你。

1.2 选 PaddleOCR + PaddleHub Serving 的三个理由，以及它们的保质期

当时选型其实不算草率。第一个理由是中文字识别效果，PaddleOCR 在通用场景下的检测加识别组合拳开箱即用，角度分类也带上了，省掉大量调参工作；第二个理由是它自带一套服务化封装，PaddleHub Serving提供了hub serving start -m ch_ocr这种一行命令起服务的模式，对不熟悉 Web 框架的人来说门槛极低；第三个理由是生态完整，从训练到推理到服务有一套相对连贯的文档。

问题在于，这三个理由都有保质期。效果这件事跟版本强相关，老版本模型换不回新版本的效果；而"一行命令起服务"这种便利，恰恰是最容易被上游放弃的部分。我在事后才意识到，PaddleHub Serving 这条路径在官方叙事里已经逐步让位给更新的推理部署方案，PaddleOCR 仓库里那个deploy/hubserving目录在较新的版本里也被拿掉了，转向更高层的封装。也就是说，我选的不是一个"经典稳定方案"，而是一个"正在退场的方案"，这两者的维护成本完全是两回事。

这里有一条我现在会写进任何选型文档的规则：**判断一个部署方案值不值得投入，除了看它能不能用，还要看它最近一年有没有被官方放在主推路径上。**一个正在退场的模块，意味着你未来查到的所有资料都会逐渐失效，你踩的坑也没有人再填。这跟技术难度无关，是纯粹的维护成本问题。

1.3 动手前的错误假设清单

复盘的时候我把当时的心理活动写了下来，发现有五个假设，每一个单独看都挺合理，组合起来就是灾难。

• 假设一：pip 能装上就代表能跑。实际上很多包能"装完"，但import的瞬间才暴露链接库版本不匹配。
• 假设二：老版本软件能找到"最后一版支持它"的组合。理论正确，实践上要同时对齐 Python、numpy、opencv、protobuf 七八个包的版本，工作量远超预期。
• 假设三：编译能解决一切。编译能解决接口问题，解决不了 ABI 和基础库的问题，而且会引入新的依赖黑洞。
• 假设四：Docker 能绕过用户态依赖。这个假设本身是对的，但它把问题从"库版本"转移到了"内核和存储驱动"，只是换了个地方卡住。
• 假设五：失败只是差一步。这是最危险的一条，它会让你不断追加投入，而每次追加的沉没成本又成为继续投入的理由。

我把这五条写出来，是因为它们不是我个人特有的思维误区，而是所有在老环境上做新部署的人都会走的心理路径。识别出自己正在走这条路径，比掌握任何一个具体命令都值钱。

2. 从第一条 pip 报错开始：整条失败链路是怎么一节节断掉的

2.1 第一个坑：pip 装到了 2.7 解释器上

第一天的第一个小时就浪费在一个非常低级的问题上。我在终端敲pip install paddlepaddle，等了一会儿返回成功，然后python3 -c "import paddle"报模块不存在。原因很简单：系统里pip默认绑定的是 Python 2.7，而我要用的是 3.4。这个坑在有多版本 Python 的机器上极其常见，但在老系统上更隐蔽，因为python3 -m pip可能压根不存在——3.4 时代的ensurepip覆盖不全，get-pip.py的新版本又已经不支持 3.4 了，脚本会直接告诉你需要更高版本的解释器。

解决方式是用老版本的引导脚本，或者干脆去找对应版本的pipwheel 手动装。但这里已经出现了第一个信号：**这个环境连包管理器本身都处在"需要考古"的状态。**后面每装一个包，你都要经历一次"最新版不支持，去找最后一个支持版本"的循环，而每个包的最后一个支持版本又不一定互相兼容。这种感觉很像在拼一副缺了很多块的拼图，你不知道缺的那块到底存在不存在。

我用下面的命令确认了解释器和 pip 的对应关系，这个习惯后来一直保留：

python3 -V # 3.4.3 python3 -c "import sys; print(sys.executable)" python3 -m pip -V 2>/dev/null || echo "no pip for py3" which -a pip pip3 python python3 head -n 1 $(which pip) # 看 shebang 指向哪个解释器

head -n 1这一招特别实用，任何脚本的第一行都能直接告诉你它绑的是谁。老机器上所有"装了但用不了"的怪事，八成都能用这一行定位。

2.2 第二个坑：paddlepaddle 的 wheel 根本没有 cp34 标签

把 pip 修好之后，真正的墙出现了。python3 -m pip install paddlepaddle返回的是No matching distribution found for paddlepaddle。这不是网络问题，是索引里根本没有cp34这个标签的轮子。推理框架的官方轮子长期只覆盖 Python 3.6 及以上，2.0 之后的版本更是把下限提得更高，3.4 这个版本连"顺手支持一下"的窗口期都没赶上。

我不死心，去翻了历史版本，想找"最后一个支持 3.4 的 Paddle"。结果是：更早的 1.x 系列覆盖的是 2.7、3.5、3.6 这几个解释器，3.4 恰好卡在中间——既不是当时的默认版本，也不是重点测试对象。这个发现挺打击人的，因为它意味着不是"新版本不支持"，而是"从来没有认真支持过"。有些环境是"退版本能解决"，有些环境是"从来没有过那条路"，这两种情况的应对策略完全不同。

顺带说一句，很多人看到No matching distribution的第一反应是换源。换源能解决的是"源里没有同步"，解决不了"官方从来没有发布过这个标签的轮子"。判断方法很简单，去索引页面看一眼文件名列表，如果有cp36、cp37、cp38却唯独没有cp34，那就不用再试了，换十个源也一样。

2.3 第三个坑：就算装上 Paddle，PaddleOCR 的依赖树也过不了

假设我用某种非常规手段把 Paddle 装上去了（比如找第三方编译的包，或者从别的机器拷一份），下一个关卡是 PaddleOCR 自己的依赖树。它会拉进来一长串东西：opencv-python、numpy、shapely、pyclipper、Pillow、protobuf、scikit-image等等。这些包在 2019 年之后陆续把 Python 下限提到了 3.6 甚至更高，而它们的"最后一个支持 3.4 的版本"又分别落在不同的年份，互相之间的 API 也不见得像你期待的那样兼容。

最典型的例子是numpy。新版本早就不要 3.4 了，能找到的老版本在 ABI 上又和某些轮子编译时的 numpy 版本对不上。opencv-python更麻烦，它提供的预编译轮子对libGL、libstdc++都有要求，GLIBCXX版本不够时会直接抛出version 'GLIBCXX_3.4.21' not found这类错误。这个错误信息看起来指向编译器，实际上指向的是系统里那份libstdc++.so.6太老，而替换它又会影响系统上所有已经编译好的程序——这是老机器上最不能随便动的东西之一。

所以这个坑的性质和前两个不一样：前两个是"找不到"，这个是"找得到但装完之后互相打架"。前者你还有明确的搜索目标，后者你面对的是一个组合爆炸的版本空间，而每一轮尝试都要花掉十几分钟到半小时。我在这个阶段耗掉了大半天，最后是靠一条原则脱身的：当依赖组合数超过你能在两小时内穷举的范围时，就该换方案，而不是继续缩小范围。

2.4 第四个坑：PaddleHub Serving 这条部署方式本身已经过期了

就算前三个坑都填平，还有一个更根本的问题：hub serving这条路已经在退场。我当时的计划是pip install paddlehub，然后hub serving start -m ch_ocr起服务。实际去查的时候发现，这个命令依赖的模块在新版本里被弱化甚至移除，ch_ocr这类模块名和加载方式也有变动。PaddleOCR 仓库里的deploy/hubserving目录在较新的版本中同样不再维护，官方把服务化部署的叙述重心挪到了别的推理方案上。

这一条是我认为最值得写进复盘的部分，因为它跟环境新旧无关。**一个部署方案如果在官方文档里已经不再是主推路径，那即使你的环境是全新的，也会在半年内遇到同样的问题：依赖装不上、命令改了、文档对不上、社区没人回答。**老环境只是把这个过程压缩到了"动手第一天就撞上"，反而算是幸运——它让你在投入更多之前就发现方向不对。

到这里，链路已经很清楚了：解释器太老 → 没有轮子 → 依赖树打架 → 部署方式退场。四道关卡里，前三道是环境问题，第四道是选型问题。而第四道恰恰是最致命的，因为它意味着即使我花大力气把前三道全推平，最终跑起来的也是一个没人维护的东西。

3. 我试过的四条绕路，以及它们为什么全部撞墙

3.1 路线一：升级 glibc —— 这是能搞崩整台机器的事

第一条思路很直接：GLIBCXX不够就换一份新的libstdc++，glibc太老就编一份新的塞进去。我下载了源码，configure，make，然后停在make install那一步。停下来的原因很简单：glibc是系统里几乎所有程序都链接的基础库，替换它等于给整台机器做心脏移植。一旦新的libc.so.6和系统里其它组件不匹配，连ls、ssh这种最基础的命令都可能起不来，而远程机器一旦ssh起不来，你就只能去机房。

更可行的变体是新版本编译到自定义目录，然后用patchelf或者LD_LIBRARY_PATH给特定程序指路。这条路技术上成立，但工程量极大：你不仅要保证目标程序用新的libc，还要保证它加载的每一个.so都不会反向拖进系统的旧libc，混链的后果是各种难以理解的段错误。我在这一步的判断是：为了一个 OCR 服务付出这种代价，收益和风险完全不成比例。

提示：在任何生产机器上，make install安装glibc都是我认为应当绝对避免的操作。真要做，也必须在可回滚的快照或者独立机器上先走一遍完整流程。

3.2 路线二：源码编译 Paddle —— 时间成本和编译依赖的双重黑洞

第二条思路是绕过轮子，直接编译。理论上，源码编译能适配任意 Python 版本和基础库。实际上，编译 Paddle 这种规模的推理框架，需要的东西比运行时还多：更新的编译器、CMake、若干第三方库的源码包，编译过程中还会因为各种 ABI 问题中断。

我在一台 4 核的机器上跑了两个小时，进度停留在整个构建的一半左右，中间因为某个依赖的版本不匹配中断了一次。重新配置、再跑，又在另一个地方中断。这时候我算了一笔账：即使编译成功，产出的 wheel 也只是"可能能用"，后面还有模型加载、算子兼容、服务封装一堆事。而这个编译产物是不可复现的——没有任何人会在同样的老环境上编译同样的东西，意味着出问题只能自己扛。

这条路线最终被我定性为"技术上可行、工程上不可接受"。它的诱惑在于让你觉得自己在推进，实际上是在一个没有回头路的深坑里垂直向下。

3.3 路线三：版本考古，找"能跑的最后一版"

第三条思路是最"正统"的：既然新版不支持，那就把整条链路都退到某个历史时刻，让所有组件都回到 2017 到 2018 年那个时间点。理论上，那时候的 Python 3.4 还活着，Paddle 的 1.x 系列也在维护，PaddleOCR 的前身也还没出来——问题就在最后这一条，PaddleOCR 这个项目本身起步的时间点，已经晚于 Python 3.4 的主流支持期了。

也就是说，不存在一个所有组件都对齐的"甜蜜时刻"。这就封死了版本考古这条路。我在做这个判断时用了一个很简单的方法：把关键组件的首次发布年份和最后一个支持目标环境的年份列成一张表，如果某个组件的"起点"晚于目标环境的"终点"，那这条路就不用试了，它不存在。

这条路线的教训比它本身更重要：版本考古只适用于"整条链路曾经共存过"的情况。如果目标软件是在环境淘汰之后才出现的，那无论你怎么组合版本，都拼不出来。

3.4 路线四：上 Docker，让容器去背用户态的锅

第四条思路是把锅甩给容器：容器有自己的 rootfs，用户态库版本可以任意选，跟宿主机无关。这个思路本身是对的，我在这台机器上确实见到过别人用容器跑起过很新的东西。但它把问题从"库版本"转移到了"内核和容器运行时"。

这台机器的内核是 3.13 那一代，容器运行时版本很老，存储驱动、cgroup 支持都存在限制。实际尝试的时候，拉镜像、起容器这两步就磕磕绊绊，要么是运行时版本太老不认镜像的某些字段，要么是存储驱动在旧内核上不可用。理论上这些都可通过换驱动、降运行时版本绕过，但每一次尝试都要动系统级的配置，而这又回到了我一开始设定的红线。

我把四条路线的结论整理成了下面这张表，方便你对照自己的环境判断：

3.5 四条路线的横向对照表之外的判断

表格之外还有一个维度没写进去，就是时间。前三条路线的失败不是"试了不行"，而是"试了很久才确认不行"。升级glibc花了两小时编译，源码编译花了两个多小时加一次重来，版本考古花了大半天查资料和对版本。这些时间最终没有产出任何可以交付的东西。

所以后来我给自己加了一条判断标准：**在老环境上尝试新部署，给每条路线设一个明确的时间盒。**比如"两小时内没有出现能跑通的最小验证，就换下一条路"。这条规则听起来像是在放弃，实际上是保护你不在单一方向上无限沉没。我那条"再试一把也许就成了"的心理暗示，在时间盒面前会立刻失效，因为时间是硬约束，不会因为你努力就变多。

另外还有一个经常被忽略的成本：没有产出的探索也会消耗团队信任。如果你跟业务方说"这周搞定"，然后在第三天告诉他们"环境不支持，要换方案"，对方的感受和你第一天就说清楚是完全不一样的。这也是我现在倾向于先做可行性验证、再给排期的原因。

4. 怎么在十分钟内判断"这个环境到底还有没有救"

4.1 五条命令把环境的底摸清

失败之后我把这套判断流程固化下来了。任何一台陌生机器，我上来先跑这五条，十分钟内能对"能不能装某个推理服务"有个初步结论：

#!/bin/bash # env-check.sh —— 部署前的环境体检 echo "== 发行版 ==" lsb_release -a 2>/dev/null || cat /etc/os-release echo "== 内核 ==" uname -r echo "== glibc ==" ldd --version | head -n 1 echo "== libstdc++ 支持的 GLIBCXX 版本 ==" strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 \ | grep -E '^GLIBCXX_[0-9.]+$' | sort -V | tail -n 3 echo "== Python 解释器 ==" for p in python python2 python3; do command -v "$p" >/dev/null && echo "$p -> $($p -V 2>&1)" done

输出里最关键的三个数字是：glibc版本、GLIBCXX的最高版本、python3的major.minor。前面那个GLIBCXX的strings | sort -V | tail组合比直接看版本号更准，因为它反映的是这个.so实际导出了哪些符号，而很多报错恰恰是符号级别的。

4.2 版本矩阵：把"能装"和"能跑"分开看

拿到这些数字之后，下一步是填一张对照表。我常用的格式是这样的：

这张表的价值在于它把问题分层了。Python 版本是阻断级——版本不对，你连包都下不下来，后面的问题根本轮不到暴露。glibc 和GLIBCXX是风险级——包能下、能装，但运行时才炸，而且炸得很隐蔽。分清楚这两类，能让你在十分钟内决定"要不要开始"，而不是花了半天才发现第一道门就进不去。

4.3 一条经验法则：Python 版本是硬门槛，glibc 是软门槛

我把这条单独拎出来说，因为它帮我省了很多时间。Python 版本决定了"这个包存在不存在"，因为轮子是按 Python 的 ABI 打标签的，没有cp34就是没有，任何技巧都变不出来。glibc 和GLIBCXX决定了"这个包装上去能不能跑"，它们不阻止你下载，只在运行时告诉你符号找不到。

所以正确的判断顺序是：先看 Python 版本有没有对应轮子，有的话再看基础库版本够不够，都不够的话再看有没有"纯 Python 实现"或者"无编译依赖"的替代包。反过来做——先去折腾 glibc——就会掉进我第一天那个坑里。顺序错了，努力的方向就全错了。

再补一条：别相信"理论上兼容"这四个字。manylinux 标签意义上的兼容，和"装上去import不报错"之间有很大差距。在看到实际运行结果之前，一切版本兼容都是推测。我后来养成的习惯是，在正式动手之前先写一个三行的最小验证脚本，跑通了再往下做，跑不通就立刻停。

# smoke_test.py —— 最小验证，跑不通立刻停 import numpy, cv2 # 先验证重依赖 print("numpy", numpy.__version__) print("cv2", cv2.__version__) import paddle # 再验证框架本身 print("paddle", paddle.__version__, paddle.is_compiled_with_cuda())

这三行看着简单，但它能在一分钟内把 90% 的"装完不能用"问题暴露出来。特别是cv2那行，老系统上十次有六次是在这里报GLIBCXX相关的错。

5. 最后跑通的那条路：把推理挪走，14.04 只留一个 HTTP 客户端

5.1 新机器上的最小可用服务

绕了一圈之后我接受了现实：这台 14.04 机器不装推理框架。推理放到一台新机器上，老机器只负责调接口。这个思路不新鲜，但真正落地的时候有几个细节值得说。

新机器上的服务我用一个薄薄的 Web 层包住 PaddleOCR，理由是它比hub serving可控得多——输入输出格式我自己定，错误处理我自己写，版本升级我自己控。核心代码不到三十行：

# server.py —— 用 FastAPI 包一层 PaddleOCR import io import cv2 import numpy as np from fastapi import FastAPI, UploadFile, File, HTTPException from paddleocr import PaddleOCR app = FastAPI() # 模型只加载一次，放在进程级别 ocr = PaddleOCR(use_angle_cls=True, lang="ch", show_log=False) @app.post("/ocr") async def run_ocr(file: UploadFile = File(...)): raw = await file.read() if not raw: raise HTTPException(status_code=400, detail="empty file") img = cv2.imdecode(np.frombuffer(raw, dtype=np.uint8), cv2.IMREAD_COLOR) if img is None: raise HTTPException(status_code=400, detail="decode failed") result = ocr.ocr(img, cls=True) lines = [] # PaddleOCR 返回结构按版本有差异，这里做一层收敛 for page in (result or []): for item in (page or []): box, (text, score) = item[0], item[1] lines.append({ "text": text, "score": round(float(score), 4), "box": [[int(p[0]), int(p[1])] for p in box], }) return {"count": len(lines), "lines": lines}

启动就一行uvicorn server:app --host 0.0.0.0 --port 8000 --workers 1。这里有个坑要提醒：**workers不要随手开多。**每个 worker 都是一份独立的模型副本，显存或者内存会成倍上涨，而且模型加载本身要几十秒，开四个 worker 冷启动可能超过两分钟。单 worker 加一个队列，对这种场景通常更稳。

5.2 老机器上的客户端，只要一个 requests

老机器这边的代码反而更简单，一个函数就够了：

# client.py —— 在老机器上运行，只依赖 requests import requests def ocr_file(path, url="http://10.0.0.12:8000/ocr", timeout=30): with open(path, "rb") as f: resp = requests.post(url, files={"file": f}, timeout=timeout) resp.raise_for_status() return resp.json()

但我在这台机器上又遇到了一个小插曲：老版本的requests能用，新版本装不上，而且urllib3的某些版本对这个系统上那代 OpenSSL 不友好，握手阶段会报错。最后的解法是给它锁了一个确定能用的老版本，并且把这个版本号写进了这台机器的依赖清单里。

如果连requests都搞不定（在老到一定程度的环境里这完全可能），还有一个更土但更可靠的办法：直接调curl。

#!/bin/bash # 老机器上的兜底方案：curl + 本地临时文件 IMG="$1" URL="${2:-http://10.0.0.12:8000/ocr}" curl -sS --max-time 30 -F "file=@${IMG}" "${URL}" -o /tmp/ocr_result.json echo $?

curl的好处是它是系统级的命令行工具，跟 Python 生态完全解耦，只要网络通就能用。输出的 JSON 交给上层业务进程用任意语言解析都行。这套方案我一直用到那台机器退役，没有出过问题。

5.3 这种拆分带来的额外好处和新的坑

好处比预想的多。第一，老机器上不再有任何推理相关的依赖，系统一个包都不用动，红线守住了。第二，推理服务可以独立升级、独立扩容，哪天模型换了只需要重启那一个服务。第三，故障边界清楚了：出问题先看是网络还是服务，而不是在一台什么都有的机器上猜。

新引入的坑也得说清楚。**第一个是网络。**原本是本地函数调用，现在是 HTTP，意味着你要处理超时、重试、并发和带宽。图片大的时候，传输时间可能比推理时间还长，这时候就得考虑在客户端先做缩放。**第二个是单点。**一台服务挂了，所有调用方全挂。至少要做个进程守护和健康检查接口，/healthz返回一个固定字符串就行。**第三个是错误传播。**服务端返回的 500 到了客户端可能被包装成一个看起来正常的空结果，这类问题在老代码里特别容易埋雷，所以我在客户端里坚持raise_for_status()，宁可炸也不要静默失败。

还有一点容易被忽略：老机器上的时间同步和证书。如果新服务挂了 HTTPS，老机器那代 OpenSSL 很可能握不上手。我的做法是内网走明文 HTTP，只在内网网段可达，安全边界交给网络层管，而不是让老机器去处理证书链。这是个权衡，不是最佳实践，但在这种环境里是可行解。

6. 这次失败留下的可复用检查清单

6.1 部署前的十分钟体检

现在我做任何"在老环境上装新东西"的任务，都会先跑一遍前面那套体检脚本，然后把结果写进一个固定格式的记录里。记录包含四项：环境的三个关键版本号（glibc、GLIBCXX、Python 次版本号）、目标软件的最低要求、两者的差距结论、以及"是否有纯 Python 或无编译依赖的替代品"。

这四项填完，"能不能装"这个问题基本就有答案了。如果结论是"阻断级"，那就直接跳到方案讨论，不要再花时间试。经验上，这一步能省掉至少半天。

顺便提一下第三条经常被漏掉：**"有没有替代品"这一项的价值极高。**很多场景下你要的不是某个具体框架，而是一个能力。OCR 这个能力除了 PaddleOCR，还有别的选择；如果你只是要识别印刷体数字或者固定格式的表单，甚至不需要通用 OCR 模型，模板匹配加简单分类就能解决，而这些东西在老机器上的依赖负担小得多。我后来帮另一个项目做类似判断时，直接砍掉了整个 OCR 依赖，用规则匹配解决了 80% 的场景，剩下 20% 才走远程调用。

6.2 报错定位的通用顺序

失败那两天我总结出一套报错定位顺序，后来一直在用：

1. 先看解释器对不对。which和head -n 1一起上，确认包到底装进了哪个 Python。
2. 再看是"找不到"还是"跑不了"。No matching distribution属于前者，说明这条路不存在；ImportError/symbol not found属于后者，说明环境有问题。
3. ImportError里优先看.so名字和符号名。GLIBCXX_3.4.21 not found直接指向libstdc++，libGL.so.1指向图形库，能少走很多弯路。
4. **最后才考虑编译。**编译是最后手段，不是第一选择。它耗时且不可复现，一旦失败你连"回退到 pip 安装"这个选项都没有了。

这套顺序的核心思想是：**先排除"不存在"，再排除"不兼容"，最后才考虑"自己造"。**大部分人（包括当时的我）是反着来的，一遇到安装失败就去搜怎么编译，结果把最简单的问题拖成了最复杂的问题。

6.3 我个人后来一直沿用的几条习惯

最后分享几条从这次失败里长出来的习惯，都是具体可执行的，不是空话。

**第一条：给每次尝试记录耗时和结果。**我在那两天里记了十几条"尝试 → 结果 → 耗时"，回头看的时候触目惊心：有六次尝试的耗时超过一小时且没有任何产出。如果不记，你只会记得"我努力了两天"，而不会记得"我在三个方向上各沉没了半天"。

**第二条：任何超过两小时的探索都要先有一个可交付的最小验证。**比如"能 import 并跑通一张图"，而不是"把整个服务搭起来"。最小验证跑通之前，所有架构设计都是空谈。

**第三条：把"这个方案会不会被淘汰"当成选型的一级指标。**这次失败的根因其实不是 14.04 太老，而是我选了一个正在退场的部署方式。如果换成新机器加一个正在主推的方案，14.04 这台机器的问题是可以通过"分离部署"绕过的；而我当时选的方案既要求环境新，本身又在退场，等于两个风险叠加。

**第四条：老环境的价值不是"再榨一榨"，而是"稳定地待在原地"。**这台机器后来一直跑着那个业务进程，只加了一个curl调用远程服务的脚本，没有装任何新依赖，安安静静跑到退役。回头看，这才是它最合适的用法。我花那两天最大的收获，可能就是彻底接受了这件事：不是所有机器都需要装上新东西，有些机器最好的状态就是什么都不动。

如果你也正在一台老机器上挣扎，我建议你先花十分钟跑一遍体检脚本，把 Python 版本和GLIBCXX版本这两个数字拿出来看一眼。这两个数字大概率能替你省下那两天。