简介这份资源是面向Linux离线环境的Python 3.6.5集成安装包专为内网服务器、无外网权限或需要快速搭建Python开发环境的用户准备。包内已集成NumPy、Pandas、TensorFlow 1.10等科学计算与机器学习库Django 2.1、djangorestframework 3.8、gunicorn等Web开发组件同时包含PyMySQL、SQLAlchemy、elasticsearch等数据存储与检索工具解压后即可直接使用省去逐一下载依赖的繁琐流程。资源共包含2000个文件以Python源码及编译产物py/pyc为主辅以C头文件h、动态库so、多语言翻译文件mo/po、说明文档txt/html等覆盖代码、依赖和文档三类内容整体压缩包约158.82MB目录结构完整便于定位和部署。目前已有4153人学习下载已在CentOS 6.5/7、RedHat上验证运行适合需要离线部署Python AI、Web或数据分析环境的开发者。1. 为什么还抱着 Python 3.6.5 做离线部署如果你接手的是一台连外网都要审批、yum 源只指向本地镜像的物理隔离服务器而上面还跑着依赖 Python 3.6.5 的量化回测脚本或者老版本数据处理任务那你就知道python3.6.5 linux 离线安装包不是选择题而是必答题。所谓离线安装本质是在没有外网的环境里把源码包、底层依赖库、pip 第三方包一次性带进去就地编译、就地使用。这篇文章就是给内网运维、项目接手人和被 Python 版本锁死的开发者一份可直接照着操作的清单把下载、编译、装依赖、做虚拟环境、排错这几件事一次说透。适合那些已经被隔离环境折磨过、想找一个确定路径的人。2. 离线安装前先做三件事目标机探测、依赖盘点、源码包准备2.1 目标机探测先看 glibc、gcc 和现有 Python在动手下载任何东西之前先到目标机上看清楚它的底子。很多翻车不是编译参数的问题而是目标机的 glibc 版本太老、gcc 缺失或者已经存在一个被改过的 Python。我会先跑这套命令uname -a cat /etc/os-release ldd --version | head -1 which gcc make which python3 python3 --version代码逻辑uname -a看内核和架构cat /etc/os-release看发行版名称和版本ldd --version | head -1拿 glibc 版本which gcc make确认编译工具是否存在which python3 python3 --version看系统里是否已经有 Python 以及它的版本。最后一条很关键如果系统自带的 Python 被做过软链替换后面编译安装必须用完全独立的目录避开它。参数判断Python 3.6.5 编译对 glibc 最低要求大约在 2.14 附近实际经验是 CentOS 7 这类系统的 glibc 2.17 能顺利通过CentOS 6 的老 glibc 2.12 就可能遇到个别库的兼容问题。gcc 版本建议在 4.8 以上否则 configure 阶段直接报错。这一节做完你才知道该准备哪些依赖而不是盲目开始。2.2 依赖盘点zlib、openssl、readline、sqlite 一个都不能少Python 编译时对几个底层库有硬依赖缺了它们编译能通过但跑起来后对应功能神秘消失。比如没有 zlib 的库文件pip 装第三方包会报zipimport.ZipImportError: cant decompress data没有 readline交互式 Python 的方向键和补全功能直接废掉没有 sqlite标准库里的 sqlite3 模块 import 就失败。这类问题在离线环境里最难受因为装完 Python 才发现缺功能再回头补底层库又要重新编译一遍。我一般提前在可联网的机器上把下面这批包全部下载成 rpm 或 deb 文件用 U 盘或内网共享传过去。清单按功能整理底层库相关 Python 模块漏掉后的典型翻车zlib-devel / zlib1g-devzlib、gzip、pip 解压pip 无法安装任何包openssl-develssl、hashlibimport ssl 报错pip 连 https 源失败readline-develreadline、rlcompleter交互式终端没有历史记录和补全sqlite-develsqlite3import sqlite3 直接失败bzip2-develbz2处理 bz2 压缩文件失败libffi-develctypesimport ctypes 失败tk-develtkinter不装用户无感知装了才有 GUI这张表的判断标准很简单拿不准用不用得到也建议装上。离线环境后续补装的成本往往是编译期的三到五倍因为要重新 configure、重新 make还要处理升级底层库后 glibc 符号变化带来的连锁问题。与其赌运气不如一次性带全。2.3 源码包获取下载、校验、传内网在可联网的开发机上去 Python 官网源码区拿 Python 3.6.5 的源码包注意文件名对应准别拿成 Windows 安装包。拿到以后做一次完整性校验md5sum Python-3.6.5.tgz sha256sum Python-3.6.5.tgz校验逻辑md5 和 sha256 分别计算摘要然后和官网发布页面给出的值逐字比对任何一个不一致都不能用。离线部署最怕的是一路拷过去、装到一半发现压缩包损坏。校验通过后把源码包、底层依赖库文件、以及后面要做的 pip 离线包放进同一个目录打包传进内网。常见做法是用 tar 打包传到目标机后解压到固定目录比如/opt/offline_pkg。整个过程里最容易犯的错是只带源码包依赖全没带导致目标机上 yum 也装不了瞬间进入死局。所以我会在可联网机器上把所有依赖拉齐宁可多带文件。这里有个替代做法值得提如果目标机的内网 yum 源其实存在这些依赖包那不需要自己下载 rpm可以直接在目标机上执行yum list zlib-devel看看能不能出结果。大部分隔离内网的镜像源往往只同步了基础包devel 系列不一定会同步所以我还是倾向自己准备一份多一道保险。3. 编译安装 Python 3.6.5依赖库、configure 参数与 make install3.1 先装底层依赖库离线 rpm 的安装顺序依赖库要按依赖关系装不是一股脑全装。rpm 包的依赖链可能导致你先装 zlib-devel 时提示缺别的包所以先把所有 rpm 放同一目录用一条通配命令让系统自动按依赖解析cd /opt/offline_pkg/rpms rpm -Uvh --nodeps *.rpm命令说明-Uvh是升级安装并打印过程--nodeps跳过依赖检查在离线环境里能强行把整批包装上去。注意它是把双刃剑跳过依赖检查可能装出缺核心库的残废包。我一般只在最后反复卡依赖时才用它装完立刻做一次校验。如果是 Debian/Ubuntu 的离线环境对应命令是dpkg -i *.deb同样可能报依赖错需要配合apt-get -f install修复但完全离线时这个修复也依赖本地缓存。装完依赖后用ldconfig -p | grep -E zlib|ssl|readline确认库文件进入了系统缓存。这一步很关键库文件存在不代表动态加载器找得到有些内网环境管理得严/usr/local/lib不在默认搜索路径里后面 Python 编译时会出现找到头文件但找不到动态库的诡异报错。3.2 configure 参数怎么设prefix、ssl、enable-shared接下来是核心编译环节。源码包解压后进入目录我的标准动作是配一个独立安装前缀避免污染系统自带的 Pythontar -xzf Python-3.6.5.tgz cd Python-3.6.5 ./configure --prefix/usr/local/python365 \ --with-ssl \ --enable-shared参数说明--prefix指定安装目录后续所有可执行文件和库都落到/usr/local/python365下不覆盖系统的/usr/bin/python--with-ssl让 ssl 模块明确编进去--enable-shared生成 libpython 动态库这是后续多个项目共用 Python 时的标配但会加长编译时间。--enable-optimizations这个参数会做 PGO 优化编译时间翻两三倍离线环境机器性能一般建议去掉没必要为一点运行时提升把部署拖成半天。如果目标机上的 openssl 不在系统默认路径比如你自己编译过 openssl 放在/usr/local/opensslconfigure 时要额外指定./configure --prefix/usr/local/python365 \ --with-openssl/usr/local/openssl这里要泼一盆冷水Python 3.6 对 OpenSSL 1.1 的适配已经够用但如果你在 import ssl 之后做握手测试时报错优先检查系统里是不是同时存在多个 openssl 版本导致头文件和库文件不一致。这类问题在离线环境属于经典玄学原因基本是路径混乱把依赖路径理顺就能解决。3.3 make 与 make install编译报错的常用排查顺序configure 通过之后进入编译。这里给新手一个心理预期make 阶段报错非常正常关键是按顺序排查。make -j$(nproc) make installmake -j后面的数字是并行线程数nproc返回当前机器核心数。内网老机器如果内存只有 2G并行编译容易把内存打满导致进程被杀保守一点就写make -j2或直接make。make 报错时先看最后十行日志绝大多数问题集中在两类一是缺头文件报错里有fatal error: xxx.h: No such file or directory说明对应的-devel包没装全二是缺库符号报错里有undefined reference to SSL_xxx说明 openssl 库版本不搭配。前者回到 2.2 的清单对照后者检查 openssl 路径参数。make install 执行完成后不要急着删源码目录。我见过很多人在 install 完成后立刻把源码包删掉结果后来想重新编译加某个模块时不得不重新找包带进内网。源码目录留着只是多用几百 MB 磁盘换来的是后面排错的后悔药。3.4 环境变量与软链接让 python3.6 被系统找到安装完成后把路径写进系统环境。注意这里刻意不直接覆盖/usr/bin/python3因为很多内网系统的工具链已经依赖了系统旧版本强行替换容易把系统搞崩。ln -s /usr/local/python365/bin/python3.6 /usr/local/bin/python3.6 ln -s /usr/local/python365/bin/pip3.6 /usr/local/bin/pip3.6 echo export PATH/usr/local/python365/bin:$PATH /etc/profile.d/python365.sh source /etc/profile.d/python365.sh软链接只建到/usr/local/bin然后把/usr/local/python365/bin加进 PATH。这样做的逻辑是python3.6这个命令会被优先找到但系统的/usr/bin/python完全没被动过。如果你把链接直接放在/usr/bin下之后一旦有应用依赖系统自带的 Python 3.x 且版本不同你会陷入到底是谁覆盖了谁的泥潭。source 之后执行python3.6 -V看到的应该是Python 3.6.5。4. 离线建虚拟环境与 pip 依赖包迁移4.1 为什么必须建虚拟环境而不是全程用系统级包离线环境没有外网一旦把第三方包直接装进系统级 site-packages后续版本升级和回滚都是灾难。虚拟环境的价值是把一套依赖完整隔离进一个目录出问题时直接删目录重来代价远低于把系统环境反复改写。Python 3.6.5 自带 venv 模块但它依赖 ensurepip而 ensurepip 在离线环境里经常因为缺 pip 的 ensurepip 数据而失败这是离线部署最容易踩的坑。我的习惯是优先用 virtualenv。原因不是 venv 不好而是 virtualenv 对离线场景容错更好它允许你在创建环境时指定本地 pip 路径不依赖系统联网下载。创建命令cd /opt/offline_pkg tar -xzf virtualenv-*.tar.gz python3.6 /opt/offline_pkg/virtualenv-*/virtualenv.py myenv注意这个命令用python3.6直接执行 virtualenv 的源码入口是因为内网环境可能还没装好 virtualenv 命令。如果已经在前面用 pip 装好了 virtualenv也可以直接用python3.6 -m virtualenv myenv。虚拟环境位置我习惯放在/opt/venvs/myenv不放在项目目录里项目目录一旦整体替换环境也会连带丢失。创建完后激活脚本在myenv/bin/activate执行source myenv/bin/activate后提示符会带上(myenv)前缀。4.2 在联网机器上准备 wheel 包pip download 的正确姿势虚拟环境建好之后下一步是项目依赖的离线包准备。这个动作在可联网开发机完成核心命令pip3.6 download -r requirements.txt \ -d /tmp/offline_wheels \ --platform manylinux2014_x86_64 \ --python-version 36 \ --implementation cp \ --abi cp36m \ --only-binary:all:命令解释-r指定依赖清单-d指定存放 wheel 的目录--platform精确指定目标平台为 manylinux2014 x86_64避免下载到 Mac 或 Windows 的包--python-version 36锁定 CPython 3.6--abi cp36m配套指定 ABI 标签--only-binary:all:强制只下载编译好的 wheel不下载源码包。参数里最值得关注的是--platform和--python-version。很多人不管这两个参数直接pip download -r requirements.txt结果下一堆 tar.gz 源码包到了内网装的时候发现还需要编译工具链编译又缺依赖整个链路直接断裂。如果你不确定目标机的架构可以在开发机上用pip debug --verbose查看当前环境的兼容标签列表照着匹配的 tag 来指。4.3 内网批量安装与版本锁定把整个/tmp/offline_wheels目录传到目标机进入虚拟环境使用本地目录作为唯一安装源source /opt/venvs/myenv/bin/activate pip3.6 install --no-index --find-links/opt/offline_pkg/wheels \ -r requirements.txt--no-index的意思是完全不从 PyPI 或任何远程源检索--find-links指定从本地目录找包。这两个参数缺一不可只加--find-links不加--no-indexpip 在本地找不到某个包时依然会尝试访问外网源然后在离线环境里长时间卡住最后超时。安装完成后用pip3.6 freeze导出实际版本pip3.6 freeze /opt/offline_pkg/requirements_lock.txt这份清单和 wheel 目录放一起就是后续任何一次重新部署的基线。以后任何一台新机器都是同一套流程建虚拟环境、--no-index装 wheel、比对 freeze 结果。版本锁定的意义在离线环境里尤其重要因为没有外网意味着你无法轻易升级补丁唯一可靠的做法就是从第一天起让所有机器用同一组精确版本。5. 离线安装避坑五个高频翻车点与排查思路5.1 现象make 阶段报错 missing zlib module编译到 zlib 相关模块时提示找不到头文件或者最后提示缺失模块。原因是 zlib-devel 没装上Python 编译时自动降级跳过 zlib 模块。解决方法是装好 zlib-devel 后删除源码目录下的相关缓存重新 configure。注意不要只重新执行 make install先make clean再从头编译否则旧的配置和中间文件还在问题会原样复现。5.2 现象python3.6 启动后 import ssl 报 ModuleNotFoundError这个问题常见原因是系统存在两个 openssl 版本Python 编译时抓到了旧版本头文件加载时又找到新版本动态库两边不一致。解决思路是 configure 时明确指定--with-openssl指向一个确定的安装目录保证运行时按编译路径搜索。检查命令是python3.6 -c import ssl; print(ssl.OPENSSL_VERSION)如果打印的信息和系统 openssl 版本对不上基本就是路径错乱。5.3 现象configure 时提示 no acceptable C compiler目标机没装 gcc 或 gcc 版本过老。离线环境里装编译器又依赖一堆库这属于最麻烦的一类。如果完全没有编译条件想靠交叉编译再拷过来不现实最稳的办法还是把 gcc 及其依赖的 rpm 带进内网装上。gcc 的依赖链比 Python 本身还深建议在可联网机器上用yumdownloader --resolve方式拉全整套文件再整体传入。5.4 现象make install 后 python3.6 -V 显示的还是旧版本原因基本是安装目录没加入 PATH或系统里已有同名软链指向旧版本。解决方法是检查which python3.6指向哪里同时用/usr/local/python365/bin/python3.6 -V看实际版本。如果实际版本正确而命令版本不对调整 PATH 把安装目录放到前面即可。这里最容易犯的错是把新 Python 的软链直接覆盖到/usr/bin/python导致系统工具链因 Python 语法版本变化而大面积报错。5.5 现象离线 pip install 时报错 Could not find a version that satisfies the requirement这个报错几乎可以断定是--find-links目录里根本没有匹配当前平台的 wheel。原因通常有两个一是下载 wheel 时没加--only-binary导致下载的是源码包而离线环境又没有编译条件二是--platform、--python-version参数标错比如在 Python 3.11 开发机上没指定--python-version 36结果拿到 3.11 的 wheel。解决方法是回到联网机器重新生成目录核对文件名里的 cp36 标记。6. 收尾验证一条命令确认安装可用与固化基线整套环境是否真正可用需要一条同时验证版本、ssl、虚拟环境、第三方包导入的命令。我习惯把它存在固定运维脚本位置每次部署跑一遍python3.6 -V \ python3.6 -c import ssl, zlib, sqlite3; print(core modules ok) \ source /opt/venvs/myenv/bin/activate python3.6 -c import requests; print(requests.__version__)这条命令分三段第一段看版本第二段确认三个最容易缺的核心模块第三段在虚拟环境里验证项目关键依赖真实可用。如果第三段报错问题只可能出在 wheel 下载阶段不会牵涉编译层排错范围大幅缩小。接下来固化基线。把requirements_lock.txt、wheel 目录、Python 源码包、底层依赖 rpm 全部归档到一个固定目录同时把部署步骤压缩成一份短文档。我的习惯是每台机器部署完把/usr/local/python365目录做一次 tar 打包留存后续新机器如果硬件架构一致可以直接解压这个目录而不需要重新编译。这个做法能把一次四十分钟的编译压缩成五分钟的解压前提是目标机的 glibc 和底层依赖一致否则解压完依然会报动态库错误。这个技巧值得一试但一定要做好 glibc 版本比对。离线安装的本质就是提前把所有不确定项在可联网环境里消化掉真正到了内网每一步都应该是确定性的操作。希望帮到你。本文还有配套的精品资源点击获取