Python 3.6.5 Linux 离线安装全攻略：源码编译与避坑指南

简介这是一份面向Linux运维与AI开发者的Python 3.6.5离线安装包已集成科学计算、Web开发与机器学习常用库适合内网隔离或无法联网安装的生产环境直接部署。包体共2000个文件主要包含pyc/py源码、C头文件、so动态库以及大量可执行脚本另有Django管理命令、gunicorn启动工具、TensorFlow编译组件等压缩包整体约158.82MB解压后即可运行已在CentOS 6.5/7、RedHat上验证通过。内置numpy、pandas、tensorflow 1.10.0、Django 2.1.1、djangorestframework、SQLAlchemy、PyMySQL、elasticsearch等二十余个常用插件覆盖数值计算、数据库访问、REST API开发与全文检索场景同时附带时区数据库和各类资源文件开箱即用。对于使用CentOS 7等系统的开发者可显著缩短环境搭建时间避免因缺少底层依赖而反复编译报错。目前已有4154人学习下载适合需要快速搭建Python开发环境、部署离线AI服务或维护内网系统的工程师省去逐一下载依赖包的繁琐过程也便于团队离线分发与一致性管理。1. python3.6.5 linux 离线安装包先把“为什么要它”想清楚拿到一台没有外网的 Linux 部署机要跑一个三年前写好的 AI 推理项目requirements.txt 里全是 numpy 1.16、tensorflow 1.14 这种老版本系统自带的 Python 要么是 2.7 起不来要么是 3.11 连项目入口都过不去——python3.6.5 linux 离线安装包要解决的就是这个处境在没有外网、不能 pip 下载、系统权限还被锁死的机器上把一个版本精确、行为可预测的 Python 3.6.5 完整装上。它最大的价值是确定性版本固定、依赖固定、坑也固定而不是“能用就行”。适合三类人维护老项目的运维、要给内网交付 AI/ML 环境的算法工程师以及所有被外网依赖卡住部署的人。2. 离线安装的两个路线源码编译与系统包怎么选不吃亏离线装 Python 3.6.5 不是一个动作而是一条路线选择。先把两条主流路线对比清楚再动手能少走好多弯路。2.1 源码编译configure 参数决定了一半的坑源码编译是离线场景下最通用、也最可控的方案。只要目标机有 gcc、make 和内核头文件它就不依赖任何软件仓库版本精确到官方发布的 Python 3.6.5 源码本身。我一般会先按下面这套命令走一遍tar -xzf Python-3.6.5.tgz cd Python-3.6.5 ./configure --prefix/opt/python365 \ --enable-shared \ --with-ssl make -j2 make install这段命令的逻辑是解压源码、配置、编译、安装四步。--prefix/opt/python365指定独立安装目录不污染系统自带 Python--enable-shared让编译生成 libpython3.6m.so 动态库后续如果要用 C 扩展或者嵌入 Python这个库是必须的--with-ssl强制启用 ssl 模块Python 3.6.5 里 ssl 模块与 OpenSSL 的版本耦合很深显式指定可以避免编译时静默跳过。这里要提醒一句--enable-optimizations这个参数虽然能提升运行时性能但它会触发 PGO 优化编译时间会拉长到原来的两到三倍而且峰值内存占用非常高。配置差的离线机器上我建议先不加这个参数等装完验证通了你再考虑要不要重新编译。2.2 系统包管理器方案适合快速交付但版本不一定精确另一条路线是利用系统自带包管理器的离线仓库包比如 CentOS 的 RPM 或 Ubuntu 的 DEB。在有网环境把 rpm 或 deb 拉下来拷贝到内网机然后用包管理器本地安装。CentOS 7 上常见的做法是这样# 在一台有网的 CentOS 7 机器上把依赖包全部拉下来 mkdir -p /tmp/py365_rpms yumdownloader --resolve --destdir/tmp/py365_rpms \ python3 python3-pip python3-devel # 拷到内网机上用 rpm 本地安装 rpm -Uvh /tmp/py365_rpms/*.rpmyumdownloader --resolve会把命令里列出的包连同依赖一起下载--destdir指定输出目录。拷到内网后用rpm -Uvh一次装完。这个方案安装速度快依赖树由系统包管理器负责不用自己啃源码但它有一个绕不开的问题版本精度。比如 CentOS 7 仓库里的 python3 一般是 3.6.8而不是官方源码版 3.6.5两个小版本在行为上有细微差别。如果你的项目里有编译过的 C 扩展模块扩展在 3.6.5 下编译拿到 3.6.8 上运行不一定出问题但一旦出问题排查成本远超源码编译多花的那半小时。考虑维度源码编译方案系统包方案版本精确度与官方 3.6.5 完全一致取决于系统仓库镜像版本安装耗时10~30 分钟视机器性能分钟级依赖控制完全自主编译依赖系统仓库完整性维护成本需要管理 openssl、zlib 等随系统升级可控性弱适用场景严格贴合开发环境的离线交付内网机器能跑就行、快速凑活3. 装之前先把这三件事查完目录、校验与系统依赖源码包拿到手就解压 make我见过太多人跳过检查直接翻车。离线环境有一个特性出问题以后排查手段极其有限没有外网查文档、没有 pip 临时装依赖所以前置检查必须严格执行。3.1 离线包的目录结构与完整性校验一份规范的离线安装包目录里通常同时包含源码包、校验文件和说明文档。打开包以后我一般先列目录而不是急着解压tar -tzf python3.6.5_offline.tar.gz命令的作用是只列出压缩包内容不解压。正常会看到类似这样的结构Python-3.6.5.tgz SHA256SUMS.txt README.md patches/其中SHA256SUMS.txt和patches/这两个最有信息量。校验文件是用来核对源码完整性的patches 目录的存在说明这套源码可能被改过比如某公司内部把 openssl 路径替换成了自定义位置。如果解压后看到 patches我的建议是直接用包里的源码不要自己去官网重新下——因为包内的补丁可能恰好就是解决当前环境问题的关键。拿到校验文件后先做哈希校验sha256sum -c SHA256SUMS.txt逻辑是计算每个文件的 SHA256 值并与清单比对输出 OK 代表一致。这一步在离线场景下格外重要如果包在传递过程中被截断或损坏后面编译出的解释器会有一堆解释不通的怪毛病而哈希校验能把这个问题在第一步就拦住。3.2 系统依赖检查缺一个 -devel后面就少一个模块Python 3.6.5 编译期对系统库的依赖并不是写在 configure 帮助信息里的而是静默检测、缺失就跳过。最典型的就是 zlib、openssl、sqlite、libffi。装之前先检查一遍# CentOS/RHEL 上检查编译依赖是否齐全 rpm -qa | grep -E ^(gcc|make|openssl-devel|zlib-devel|bzip2-devel|readline-devel|sqlite-devel|libffi-devel)这个命令把所有与 Python 编译相关的包列出来。每一项缺失都会有具体的后续后果缺 zlib-develpip 装不了任何包因为 pip 的底层机制依赖 zlib 做压缩传输缺 openssl-develssl 模块编译不进去Python 的 ssl 交互全废缺 sqlite-develsqlite3 模块消失很多后台管理脚本直接崩缺 libffi-develctypes 缺失而不少 AI 框架的 C 扩展绑定要用它。如果检查发现缺了在离线机上有本地 yum 源的话可以直接补yum install -y gcc make openssl-devel zlib-devel bzip2-devel \ readline-devel sqlite-devel libffi-devel如果没有本地源那必须在打包离线包的时候就提前把这些 rpm 一并拉进去这也是 2.2 节里yumdownloader --resolve的真正意义——不光要拉 python3 本身还要拉编译链和开发库。4. 离线装 Python 3.6.5 的避坑清单八次里有五次踩在同一个坑上下面的每一条都是我实际在部署机旁边蹲过的代价换回来的。离线环境没有外网查询手段踩一个坑可能要白干半天。4.1 编译期翻车模块缺失与资源不足现象一make 和 make install 都成功但执行python3.6 -m pip install时直接抛ModuleNotFoundError: No module named zlib。原因configure 检查时系统缺 zlib-develPython 的 setup.py 自动跳过了 zlib 模块的编译这一步不会报错也不会警告直到跑 pip 时才暴露。解决先yum install zlib-devel然后关键一步是make clean再重新 configure、make、make install。只重跑 make install 没有用因为 configure 阶段生成的 Modules/Setup 已经把 zlib 标记为不参与编译了这个状态不会自动刷新。现象二import ssl 报ImportError: No module named _ssl。原因Python 3.6.5 的 _ssl 模块要求系统 OpenSSL 1.0.2 以上版本且必须具备开发头文件。configure 时检测不到就会静默跳过连个 warning 都不打。解决安装 openssl-devel或者如果你的内网机器有更高版本的 OpenSSL 但位置特殊用./configure --with-openssl/usr/local/ssl显式指定路径然后 clean 重编。现象三make -j4 编译到一半整个进程被系统杀掉日志末尾出现cc1: out of memory。原因编译 Python 3.6.5 时最耗内存的是编译 pgen 和多个大 C 文件-j 并行度太高小内存机器直接爆掉。解决切换为make -j2同时移除--enable-optimizations。PGO 优化会额外占用一倍以上内存在内存小于 2G 的机器上很容易翻车。先保证装上跑起来再谈优化。4.2 运行期翻车动态库找不到与 PATH 错乱现象四装好后运行/opt/python365/bin/python3.6直接报error while loading shared libraries: libpython3.6m.so.1.0: cannot open shared object file。原因配置了--enable-shared安装了动态库但安装目录 /opt/python365/lib 不在系统动态库搜索路径 ld.so.conf 里运行时找不到 libpython。解决先确认动态库确实存在然后写入 ld 配置并刷新sudo sh -c echo /opt/python365/lib /etc/ld.so.conf.d/python365.conf sudo ldconfig这套行为把 /opt/python365/lib 加入系统动态库搜索范围然后重新加载缓存。现象五python3.6 -V 输出正常但敲 pip -V 打到的却是系统自带的那个 pip甚至报错说 pip 不存在。原因PATH 环境变量里系统 Python 的目录排在 /opt/python365/bin 之前或者 pip 脚本的 shebang 写死了另一个解释器路径。这直接导致你给离线环境装包时包装进了另一个 Python 里白装。解决养成固定用python3.6 -m pip调用的习惯不要去依赖裸 pip 命令。这条习惯能省掉大量 PATH 混乱导致的隐蔽问题。5. 装完不是结束pip 离线扩展与 AI/ML 环境验证解释器装好只是第一步真实项目里面一定会用到 numpy、scipy、pandas 这种第三方包。这些包怎么在离线环境里进去是另一个高频卡点。核心思路只有一个在有网的机器上下载 wheel 包整体搬到内网用 pip 的本地模式安装。5.1 在联网机器上先拉出完整 wheel 集不要把项目 requirements.txt 里的每个包手工下载让 pip 自己把依赖树递归拉全# 联网机上用 Python 3.6.5 的环境执行 pip3.6 download -r requirements.txt -d /data/wheels/pip download会把 requirements.txt 里的每个包以及它们的传递依赖全部下载到/data/wheels/目录文件格式为 wheel 或 tar.gz。这里有个重要前提执行下载的环境必须与内网机解释器版本一致尽量也用 Python 3.6.5。这样 pip 才会解析出cp36-cp36m-标记的兼容 wheel。5.2 内网机安装与验证内网机上不需要访问任何仓库直接用本地目录安装python3.6 -m pip install --no-index --find-links/data/wheels/ -r requirements.txt--no-index强制 pip 不访问 PyPI--find-links让 pip 只在本地目录里找候选包-r指定 requirements 文件。三个参数配合安装过程全程离线。安装完之后不要急着跑项目先用一段验证脚本确认核心栈可用python3.6 -c import tensorflow as tf; print(tensorflow, tf.__version__) 2/dev/null || \ python3.6 -c import numpy, scipy, pandas; print(numpy, numpy.__version__); print(scipy, scipy.__version__); print(pandas, pandas.__version__)这段命令优先检测 AI 框架是否可用框架起不来就退一步验证基础科学计算栈两条命令只要跑通一条就说明解释器、pip、第三方包三层全链路是通的。如果两条都失败先跑python3.6 -c import zlib, ssl, sqlite3; print(core ok)排查是解释器模块缺失还是第三方包兼容问题。我这里还建议你把上面验证逻辑写成一个verify_env.sh每次部署完都跑一遍输出丢进交付文档。这块投入的时间往往能省掉后面无数个半夜问题电话。注意如果 pip 安装时提示... is not a supported wheel on this platform大概率是 wheel 的 cp36 标记与解释器不匹配或者内网机 glibc 版本太低。检查 wheel 文件名里的cp36与manylinux标记并确认目标机 glibc 版本与下载时一致。6. 更省事的长久习惯用 venv 把离线环境固化成基线6.1 为什么不直接往系统里装装好的 /opt/python365 是解释器本体但项目里跑起来的不只是解释器还有一堆第三方包。如果直接把包装进全局 site-packages那么不同项目之间的依赖冲突会越积越多——A 项目要 numpy 1.16B 项目要 numpy 1.23遇到这种冲突时就只能干瞪眼。我习惯的做法是解释器用全局的项目环境用 venv 隔离。6.2 用 requirements 文件加 wheels 目录固定基线venv 的好处是干净、可重建、不起冲突。但 venv 有个特性它不可直接迁移虚拟环境的 bin/python 和 pyvenv.cfg 里写的是原解释器的绝对路径整体拷到另一台机器上很容易失效。因此我把“可迁移”的希望放在 requirements 文件上而不是 venv 目录本身# 联网机上冻结当前环境并下载所有 wheel pip freeze /data/baseline/requirements.txt pip download -r /data/baseline/requirements.txt -d /data/baseline/wheels/ # 内网机上同样的解释器版本重建 venv /opt/python365/bin/python3.6 -m venv /opt/venv/proj source /opt/venv/proj/bin/activate pip install --no-index --find-links/data/baseline/wheels/ -r /data/baseline/requirements.txt冻结出来的 requirements.txt 把每个包的精确版本号锁死wheels 目录保证离线可安装venv 保证环境隔离互不干扰。这套组合拳打下来整个环境就是一台“可复制的黑匣子”——换机器、换机器、重新部署都按同一个步骤走。从那以后我每次交付离线环境都强制走一遍“联网机拉 wheels → 内网机装解释器 → venv 重建 → 导入验证”这四步再没被环境问题半夜叫起来过。希望帮到你。本文还有配套的精品资源点击获取