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.3python指向 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 第三个坑就算装上 PaddlePaddleOCR 的依赖树也过不了假设我用某种非常规手段把 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不够就换一份新的libstdcglibc太老就编一份新的塞进去。我下载了源码configuremake然后停在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 支持都存在限制。实际尝试的时候拉镜像、起容器这两步就磕磕绊绊要么是运行时版本太老不认镜像的某些字段要么是存储驱动在旧内核上不可用。理论上这些都可通过换驱动、降运行时版本绕过但每一次尝试都要动系统级的配置而这又回到了我一开始设定的红线。我把四条路线的结论整理成了下面这张表方便你对照自己的环境判断路线表面看能解决什么实际卡在哪对系统的侵入性我的结论升级 glibc / libstdc解决GLIBCXX版本报错全系统基础库混链后患无穷极高可致机器失联不选源码编译 Paddle绕过轮子的 Python 版本限制编译依赖、ABI、不可复现中但时间长且成功率低不选版本考古用老组合凑出可用环境目标软件的起点晚于环境的终点低不成立Docker绕过用户态依赖旧内核 旧运行时 存储驱动中到高需动系统配置有条件可用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 21) done输出里最关键的三个数字是glibc版本、GLIBCXX的最高版本、python3的major.minor。前面那个GLIBCXX的strings | sort -V | tail组合比直接看版本号更准因为它反映的是这个.so实际导出了哪些符号而很多报错恰恰是符号级别的。4.2 版本矩阵把能装和能跑分开看拿到这些数字之后下一步是填一张对照表。我常用的格式是这样的检查项目标软件要求常见取值本机实际影响等级Python3.6 及以上新版为 3.8 及以上3.4.3阻断级无对应轮子pip / setuptools与 Python 版本匹配需手工降级阻断级连装包都难glibc2.17manylinux2014到 2.28 不等2.19视轮子而定可能能装不能跑GLIBCXX常见要求 3.4.21 以上3.4.19高风险import阶段报错OpenSSL新版 cryptography / urllib3 要求 1.1.11.0.1 那一代中影响下载与加密相关依赖内核容器化需较新特性3.13 那一代中影响 Docker 路线可行性这张表的价值在于它把问题分层了。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_clsTrue, langch, show_logFalse) app.post(/ocr) async def run_ocr(file: UploadFile File(...)): raw await file.read() if not raw: raise HTTPException(status_code400, detailempty file) img cv2.imdecode(np.frombuffer(raw, dtypenp.uint8), cv2.IMREAD_COLOR) if img is None: raise HTTPException(status_code400, detaildecode failed) result ocr.ocr(img, clsTrue) 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, urlhttp://10.0.0.12:8000/ocr, timeout30): with open(path, rb) as f: resp requests.post(url, files{file: f}, timeouttimeout) 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 报错定位的通用顺序失败那两天我总结出一套报错定位顺序后来一直在用先看解释器对不对。which和head -n 1一起上确认包到底装进了哪个 Python。再看是找不到还是跑不了。No matching distribution属于前者说明这条路不存在ImportError/symbol not found属于后者说明环境有问题。ImportError里优先看.so名字和符号名。GLIBCXX_3.4.21 not found直接指向libstdclibGL.so.1指向图形库能少走很多弯路。**最后才考虑编译。**编译是最后手段不是第一选择。它耗时且不可复现一旦失败你连回退到 pip 安装这个选项都没有了。这套顺序的核心思想是**先排除不存在再排除不兼容最后才考虑自己造。**大部分人包括当时的我是反着来的一遇到安装失败就去搜怎么编译结果把最简单的问题拖成了最复杂的问题。6.3 我个人后来一直沿用的几条习惯最后分享几条从这次失败里长出来的习惯都是具体可执行的不是空话。**第一条给每次尝试记录耗时和结果。**我在那两天里记了十几条尝试 → 结果 → 耗时回头看的时候触目惊心有六次尝试的耗时超过一小时且没有任何产出。如果不记你只会记得我努力了两天而不会记得我在三个方向上各沉没了半天。**第二条任何超过两小时的探索都要先有一个可交付的最小验证。**比如能 import 并跑通一张图而不是把整个服务搭起来。最小验证跑通之前所有架构设计都是空谈。**第三条把这个方案会不会被淘汰当成选型的一级指标。**这次失败的根因其实不是 14.04 太老而是我选了一个正在退场的部署方式。如果换成新机器加一个正在主推的方案14.04 这台机器的问题是可以通过分离部署绕过的而我当时选的方案既要求环境新本身又在退场等于两个风险叠加。**第四条老环境的价值不是再榨一榨而是稳定地待在原地。**这台机器后来一直跑着那个业务进程只加了一个curl调用远程服务的脚本没有装任何新依赖安安静静跑到退役。回头看这才是它最合适的用法。我花那两天最大的收获可能就是彻底接受了这件事不是所有机器都需要装上新东西有些机器最好的状态就是什么都不动。如果你也正在一台老机器上挣扎我建议你先花十分钟跑一遍体检脚本把 Python 版本和GLIBCXX版本这两个数字拿出来看一眼。这两个数字大概率能替你省下那两天。
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.3python指向 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 第三个坑就算装上 PaddlePaddleOCR 的依赖树也过不了假设我用某种非常规手段把 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不够就换一份新的libstdcglibc太老就编一份新的塞进去。我下载了源码configuremake然后停在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 支持都存在限制。实际尝试的时候拉镜像、起容器这两步就磕磕绊绊要么是运行时版本太老不认镜像的某些字段要么是存储驱动在旧内核上不可用。理论上这些都可通过换驱动、降运行时版本绕过但每一次尝试都要动系统级的配置而这又回到了我一开始设定的红线。我把四条路线的结论整理成了下面这张表方便你对照自己的环境判断路线表面看能解决什么实际卡在哪对系统的侵入性我的结论升级 glibc / libstdc解决GLIBCXX版本报错全系统基础库混链后患无穷极高可致机器失联不选源码编译 Paddle绕过轮子的 Python 版本限制编译依赖、ABI、不可复现中但时间长且成功率低不选版本考古用老组合凑出可用环境目标软件的起点晚于环境的终点低不成立Docker绕过用户态依赖旧内核 旧运行时 存储驱动中到高需动系统配置有条件可用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 21) done输出里最关键的三个数字是glibc版本、GLIBCXX的最高版本、python3的major.minor。前面那个GLIBCXX的strings | sort -V | tail组合比直接看版本号更准因为它反映的是这个.so实际导出了哪些符号而很多报错恰恰是符号级别的。4.2 版本矩阵把能装和能跑分开看拿到这些数字之后下一步是填一张对照表。我常用的格式是这样的检查项目标软件要求常见取值本机实际影响等级Python3.6 及以上新版为 3.8 及以上3.4.3阻断级无对应轮子pip / setuptools与 Python 版本匹配需手工降级阻断级连装包都难glibc2.17manylinux2014到 2.28 不等2.19视轮子而定可能能装不能跑GLIBCXX常见要求 3.4.21 以上3.4.19高风险import阶段报错OpenSSL新版 cryptography / urllib3 要求 1.1.11.0.1 那一代中影响下载与加密相关依赖内核容器化需较新特性3.13 那一代中影响 Docker 路线可行性这张表的价值在于它把问题分层了。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_clsTrue, langch, show_logFalse) app.post(/ocr) async def run_ocr(file: UploadFile File(...)): raw await file.read() if not raw: raise HTTPException(status_code400, detailempty file) img cv2.imdecode(np.frombuffer(raw, dtypenp.uint8), cv2.IMREAD_COLOR) if img is None: raise HTTPException(status_code400, detaildecode failed) result ocr.ocr(img, clsTrue) 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, urlhttp://10.0.0.12:8000/ocr, timeout30): with open(path, rb) as f: resp requests.post(url, files{file: f}, timeouttimeout) 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 报错定位的通用顺序失败那两天我总结出一套报错定位顺序后来一直在用先看解释器对不对。which和head -n 1一起上确认包到底装进了哪个 Python。再看是找不到还是跑不了。No matching distribution属于前者说明这条路不存在ImportError/symbol not found属于后者说明环境有问题。ImportError里优先看.so名字和符号名。GLIBCXX_3.4.21 not found直接指向libstdclibGL.so.1指向图形库能少走很多弯路。**最后才考虑编译。**编译是最后手段不是第一选择。它耗时且不可复现一旦失败你连回退到 pip 安装这个选项都没有了。这套顺序的核心思想是**先排除不存在再排除不兼容最后才考虑自己造。**大部分人包括当时的我是反着来的一遇到安装失败就去搜怎么编译结果把最简单的问题拖成了最复杂的问题。6.3 我个人后来一直沿用的几条习惯最后分享几条从这次失败里长出来的习惯都是具体可执行的不是空话。**第一条给每次尝试记录耗时和结果。**我在那两天里记了十几条尝试 → 结果 → 耗时回头看的时候触目惊心有六次尝试的耗时超过一小时且没有任何产出。如果不记你只会记得我努力了两天而不会记得我在三个方向上各沉没了半天。**第二条任何超过两小时的探索都要先有一个可交付的最小验证。**比如能 import 并跑通一张图而不是把整个服务搭起来。最小验证跑通之前所有架构设计都是空谈。**第三条把这个方案会不会被淘汰当成选型的一级指标。**这次失败的根因其实不是 14.04 太老而是我选了一个正在退场的部署方式。如果换成新机器加一个正在主推的方案14.04 这台机器的问题是可以通过分离部署绕过的而我当时选的方案既要求环境新本身又在退场等于两个风险叠加。**第四条老环境的价值不是再榨一榨而是稳定地待在原地。**这台机器后来一直跑着那个业务进程只加了一个curl调用远程服务的脚本没有装任何新依赖安安静静跑到退役。回头看这才是它最合适的用法。我花那两天最大的收获可能就是彻底接受了这件事不是所有机器都需要装上新东西有些机器最好的状态就是什么都不动。如果你也正在一台老机器上挣扎我建议你先花十分钟跑一遍体检脚本把 Python 版本和GLIBCXX版本这两个数字拿出来看一眼。这两个数字大概率能替你省下那两天。
