简介：Python 3.7.3是面向Windows平台的官方安装包，适合编程入门者、数据分析学习者及Web开发人员快速搭建Python运行环境。压缩包共4个文件，以.exe图形化安装程序为核心，另含htm格式的安装指导文档、txt格式的下载来源说明以及一个url站点快捷方式，整体体积约为23.98MB。已有2285人浏览学习，可用于本地开发、脚本编写或项目依赖部署。该版本在2018年发布，带来了字典插入顺序保留、@dataclass数据类、类型注解增强、asyncio异步支持改进、pathlib路径操作优化等实用特性，能有效减少样板代码并提升开发效率。配套的htm说明文档提供了详细的安装指引，包括环境变量配置与安装验证方法，txt文档则补充了下载站点的使用说明，读者拿到后即可按照文档完成安装，快速体验Python 3.7的关键改进。
1. 还在装 Python 3.7？先搞清楚它到底能解决什么
一个做图像处理 Demo 的开发者，某天收到一条线上告警：跑了两年的数据处理服务突然崩了，日志指向某个依赖库的语法不兼容。他查了半天才发现，生产环境装的是 Python 3.7，而本地早就升到了 3.10，requirements.txt 里几个关键库的新版本已经不再支持 3.7。最后他花了一整天才把环境对齐。类似的场景在各行各业的存量系统里反复出现——这就是 python3.7 安装包仍然有大量搜索需求的原因。
Python 3.7 是很多遗留系统、工业软件、算法库的默认运行时。它不是最新的，但它是「能跑」的代名词。这篇笔记会讲清楚三件事：什么样的项目必须用 3.7，怎么在不同平台上干净地装好它，以及装完之后有哪些坑会让你翻车。适合手里有老项目要维护、或者因为某个依赖被迫留在 3.7 的开发者。
2. Python 3.7 的真实处境：哪些场景必须用它，哪些场景趁早升级
2.1 存量项目依赖：为什么「能跑」比「版本新」更重要
Python 3.7 发布于 2018 年，官方维护周期早已结束。但生产环境里大量服务仍然跑在 3.7 上，原因不是惰性，而是依赖锁死。常见的几类情况包括：某些工业控制库、老版本的深度学习推理框架、公司内部自研的 C 扩展模块只针对 3.7 做过编译；还有一部分是 CentOS 7 自带 Python 版本太低，开发者直接在系统 Python 上装了 3.7 然后层层叠加上业务。
这类项目的共同特征是：升级 Python 版本的代价远高于收益。你要验证所有第三方库在新版本下的行为，要重新编译 C 扩展，要处理 bytecode 缓存目录的变化，甚至有些旧库在新版本直接无法安装。对这类项目，「能跑」就是硬道理。如果你接手的是一个跑了三年的服务，第一件事不是琢磨升到 3.11，而是把 Python 3.7 环境完整复刻出来，保证行为和线上一致。
我的习惯是，遇到这种情况先确认项目里有没有 runtime.txt、.python-version 或者 Dockerfile 里固定的基础镜像版本。这几个文件直接决定了你要装哪个小版本。不要凭感觉装最新的 3.7.x，因为 3.7 系列内部的 patch 版本也有行为差异，尤其是涉及 SSL 证书验证和 timezone 数据的时候。
2.2 官方包与第三方发行版：安装包该怎么选
一说到安装包，很多人第一反应是去 python.org 下载官方安装器。对大多数场景，这是最稳妥的选择。官方有三个平台安装包：Windows 的可执行安装器、macOS 的 pkg 安装器、Linux 下的源码包。Windows 和 macOS 安装器都有图形界面，适合个人电脑；Linux 下我更推荐用 pyenv 编译安装，而不是直接用系统自带的包管理器。
为什么不用 apt 或 yum 直接装？因为系统包管理器里的 Python 3.7 往往不是完整版本，有些发行版会打补丁、改配置路径，甚至把 pip 单独拆成一个包。你装完发现 python3.7 能运行，但 pip3.7 不存在，还要再去装 python3.7-pip，一套折腾下来不如直接用 pyenv 干净。
还有一种选择是 Conda。如果你的工作流已经围绕 Conda 展开，那用conda create -n py37 python=3.7建一个环境是最省事的。Conda 的好处是自带的科学计算库预编译完整，不用自己处理编译依赖；坏处是环境体积大，而且和系统上其他 Python 工具链的交互偶尔有玄学问题。两条路都可以走，关键是选一条后别混用。
2.3 3.7 的边界：遇到这些情况就别挣扎了
Python 3.7 不是万能的，有些场景我建议你趁早死心。第一，如果项目需要用到 Python 3.8 之后才加入的语法特性，比如海象运算符在表达式中赋值以外的用法、f-string 的调试符号、或者 positional-only parameters 的某些写法，3.7 直接语法报错，没有任何安装参数能解决。第二，某些新版本库已经声明Requires-Python >= 3.8，pip 在 3.7 环境里解析依赖时会直接拒绝安装，你只能去找旧版本。
第三，也是容易被忽略的一点：如果你要跑的是新出的机器学习框架或工具链，直接用 3.7 装大概率会失败。这类项目对 Python 版本的要求很激进，官方文档都明说支持 3.9 以上。这种情况下，硬装 3.7 不是省事，是给自己找麻烦。我更建议先看清依赖声明的下限，再决定是不是要停留在 3.7。
还有一种边界是安全性的问题。3.7 不再有官方安全补丁，如果你要把服务暴露在公网，并且涉及解析不可信输入的场景，风险自负。内网工具、离线环境、受控的生产集群，用 3.7 问题不大；公网服务建议至少用一个还在维护的版本，或者在前面加一层代理做协议校验。
3. 三平台安装实操：从下载到验证的完整命令
3.1 Linux / macOS：用 pyenv 安装 3.7 的标准流程
Linux 和 macOS 上最干净的 Python 3.7 安装方式是用 pyenv 编译。pyenv 会把 Python 装到用户目录下，不碰系统自带的 Python，这对避免把系统环境搞坏至关重要。先确认本地有没有 pyenv：
# 检查 pyenv 是否已安装，没有的话先用包管理器装 pyenv --version # Ubuntu / Debian 用户： # sudo apt install -y make build-essential libssl-dev zlib1g-dev \ # libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncurses5-devpyenv 安装完成后，编译 Python 3.7 需要一些系统依赖库。这个过程里最容易出错的是缺少 libssl-dev 和 libbz2-dev，前者会导致 3.7 编译后没有 ssl 模块，后者会导致 bz2 模块缺失。很多开发者装完后用pip install时报 SSL 错误，其实就是这一步漏了。
# 列出 3.7 系列的所有小版本，选一个 pyenv install --list | grep "3.7" # 安装 3.7 系列末版 pyenv install 3.7.17 # 在某个项目目录里锁定版本 cd ~/my_legacy_project && pyenv local 3.7.17pyenv 背后的原理是源码编译，整个编译过程大约 3 到 10 分钟，取决于机器性能。装完后pyenv local会在当前目录生成一个.python-version文件，之后每次进入这个目录，python命令自动指向 3.7.17。这是我处理存量项目最常用的一套流程，因为它把版本选择完全绑定在项目目录上，不同项目互不干扰。
macOS 用户要注意一个问题：如果你装的是 Apple Silicon 芯片的 Mac，直接编译是没问题的，但某些依赖库在 3.7 下需要区分 arm64 和 x86_64 架构。常见做法是确认所有依赖都有对应架构的 wheel，如果遇到编译错误，检查一下是否在用 Rosetta 的终端里操作，两种终端环境下编出来的 Python 行为可能不一致。
3.2 Windows：安装器安装与 PATH 处理的注意点
Windows 上官方提供的 exe 安装器是最直接的路径。双击安装时，有一个关键选项容易被忽略：安装界面底部有「Add Python 3.7 to PATH」的勾选框，默认是不勾的。如果不勾，装完后你在命令行敲python会提示找不到命令，很多人以为没装上，其实只是 PATH 没配。
# 安装后验证（如果勾选了 PATH） python --version # 如果提示找不到命令，手动把 Python 安装目录加进 PATH # 常见安装位置：C:\Users\<用户名>\AppData\Local\Programs\Python\Python37 # 以及同名目录下的 Scripts 子目录Windows 安装器还有一个细节要注意：不要勾选「Install for all users」除非你确定要装到C:\Program Files下。装在用户目录的好处是不需要管理员权限，对权限受限的办公电脑特别友好。另外，安装器里可以把 pip 一并装好，它会出现在 Scripts 目录下，验证方式是在命令行里执行：
pip --version # 如果报错，确认 Scripts 目录是否在 PATH 里Windows 用户还容易遇到一个问题：电脑上已经装了 Python 3.9 或 3.11，再装 3.7 后，命令行里python指向的还是旧版本。这不是安装失败，而是 PATH 的搜索顺序问题。Windows 的 App Execution Alias 会优先把新版本放到前面，所以你可能需要调整 PATH 顺序，或者直接用py -3.7来启动 3.7 解释器。Windows 自带 Python Launcher，这个命令比改 PATH 省事得多。
3.3 安装后的最小验证：python -V 不够，还要查什么
装完 Python 3.7 之后，很多人运行python -V看到版本号就以为大功告成。这远远不够。我见过太多环境在业务代码跑起来之后才暴露出缺失：ssl 模块没编译进去，ensurepip 没有可用，sqlite3 支持为空。这些问题在python -V里全都看不出来。
# 一次性检查关键模块是否可用 python - <<'EOF' import sys, ssl, sqlite3, bz2, lzma print(sys.version) print("SSL OK:", ssl.OPENSSL_VERSION) print("SQLite OK:", sqlite3.sqlite_version) print("bz2 OK:", bz2.__name__) print("lzma OK:", lzma.__name__) EOF这段脚本输出的每一项都有实际意义。ssl 模块缺失会导致 pip 无法访问 HTTPS 源，这是最致命的问题；sqlite3 缺失会让很多用到内置数据库的业务直接崩溃；bz2 和 lzma 影响的是数据压缩和解压功能，数据处理类项目几乎必然会碰到。如果检查发现某个模块是空的，原因基本可以确定是编译前缺少对应的系统开发库，回到第一步补装依赖后重新编译。
还有一个容易被忽略的验证点是确保pip本身可用。Python 3.7 内置了ensurepip，但某些发行版或者手动编译时可能没带上。验证方式是：
python -m pip --version # 如果报错，先尝试启动 ensurepip python -m ensurepip --upgrade到这里，一个可用的 Python 3.7 就算装完了。但我还要多说一句：如果你是在容器里使用 3.7，最省心的不是手动装，而是直接找现成的官方基础镜像。拉一个python:3.7镜像，所有编译步骤都替你完成了。唯一要确认的是镜像的底层系统和你的部署目标一致，避免 glibc 版本不匹配导致运行时行为异常。
4. 装完只是开始：虚拟环境与 pip 源配置决定你能不能顺手
4.1 venv 隔离环境的标准姿势
系统级的 Python 3.7 装好后，接下来必须做的是为项目创建虚拟环境。直接往系统 Python 里pip install是一个早晚会后悔的做法，因为不同项目的依赖版本互相踩踏，装到后面你根本不知道当前环境里到底有什么。
Python 3.7 自带 venv 模块，不需要额外安装 virtualenv。创建环境的方式非常直接：
# 在项目目录下创建 .venv 目录 python -m venv .venv # 激活环境 # Linux / macOS: source .venv/bin/activate # Windows: .venv\Scripts\activate激活之后，命令行提示符会带上环境名。这时pip install装的所有包都会落到.venv目录里，不会污染全局。我个人的习惯是永远不使用deactivate或者切来切去，而是直接在当前终端里跑完业务逻辑。项目多了之后，每个终端对应一个项目环境，互不干扰，思路也清晰。
有一个 3.7 的细节需要提醒：venv 创建时会默认带上 pip，但如果你用系统包管理器装的 Python 3.7，可能没有 ensurepip 模块，导致 venv 创建失败并提示无法安装 pip。解决方式是先通过系统包管理器安装python3.7-venv这个配套包，或者回到源码编译时的依赖检查，补上 ensurepip 相关的开发包。
4.2 pip 源配置与依赖锁定
回到国内网络环境，直接使用默认 PyPI 源经常出现超时或者下载中断，解决方式是配置一个镜像源。我习惯把配置写在~/.pip/pip.conf（Linux / macOS）或者%APPDATA%\pip\pip.ini（Windows），这样所有项目都生效：
[global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple trusted-host = pypi.tuna.tsinghua.edu.cn timeout = 60这段配置只做一件事：让 pip 从镜像源拉包。timeout = 60是把连接超时时间从默认的 15 秒延长到 60 秒，对某些体积较大的包更友好。配置完成后，用pip install之前先跑一次pip config list确认配置已生效。
依赖锁定方面，在 Python 3.7 时代还没有现在这么成熟的工具链，最稳妥的方式是生成 requirements.txt 并固定版本号：
# 导出当前环境的全部依赖及精确版本 pip freeze > requirements.txt # 在另一台机器上按文件恢复 pip install -r requirements.txtpip freeze导出的文件里会包含一些间接依赖，恢复时直接按文件装。注意这里有个坑：pip freeze输出的依赖可能在平台间不一致，特别是包含编译型包时，Windows 上生成的版本号在 Linux 上未必能原样装上。跨平台迁移时，最好只锁直接依赖，把间接依赖交给 pip 的解析器去处理。
4.3 用 pipenv / poetry 管理旧版依赖的取舍
除了 requirements.txt，还有另外两条路线可以管理 Python 3.7 项目的依赖：Pipenv 和 Poetry。在 3.7 的年代，Pipenv 一度是官方推荐的方案，它把包管理和虚拟环境合在一起，pipenv install会自动创建虚拟环境并安装依赖。Poetry 则是后来者，以现代解析器著称，依赖解析更严谨。
用 Pipenv 的典型流程：
# 安装 pipenv（到当前 Python 3.7 环境） pip install pipenv # 在项目里创建环境并安装依赖 pipenv install requests==2.24.0 # 激活环境 pipenv shellPipenv 的麻烦在于它的锁文件解析速度慢，而且某些包在旧版 Python 下的依赖分析会有误判。Poetry 在 3.7 下也能用，只不过对 Python 3.7 的官方支持在 1.2 版本之后就逐渐弱化了。如果你维护的是老项目已经用 Pipenv 在管理，继续用下去没毛病；如果是从零开始，我建议直接用 venv + requirements.txt，简单可靠，出了问题也好排查。工具链越复杂，在旧版本 Python 上的兼容问题越多，这是运维层面的经验，不是理论推演。
5. 避坑指南：Python 3.7 安装路上最常翻车的 5 个地方
5.1 现象：pip install 报 SSL 证书验证失败
复现步骤是刚装完 Python 3.7，执行pip install requests，提示SSLError: certificate verify failed。刚开始以为是网络问题，反复换源也没效果，最后查了很久才发现是 Python 3.7 编译时没有正确链接系统的 OpenSSL 库。
原因是 Python 源码编译时，如果没有找到 OpenSSL 的头文件和库文件，ssl模块就不会被编译进解释器。pip 在 HTTPS 传输时依赖这个模块，没有它自然就报错。解决办法是回到编译之前，安装libssl-dev或者openssl-devel，重新运行pyenv install 3.7.17，做一个全新编译。
补充一个细节：某些 Linux 发行版的 OpenSSL 版本太新，Python 3.7 的老代码对 OpenSSL 1.1.1 以上的支持是完整的，但如果系统默认是 OpenSSL 3.0，编译时有可能遇到类型不匹配问题。这个时候需要确认openssl命令的版本，如果确实太新，考虑安装一个兼容库或者用 Docker 基础镜像解决，不要在源码编译这一棵树上吊死。
5.2 现象：解压 tar 包时提示 No module named bz2
服务部署到新机器后，一跑代码就报ModuleNotFoundError: No module named 'bz2'，查了 requirements.txt 里根本没有这个库。问题是 lzma 和 bz2 是标准库的一部分，但需要编译时对应的系统库存在。Python 3.7 编译时缺了libbz2-dev，解释器就静默地跳过了这个标准库。
解决方式和 SSL 类似，安装libbz2-dev和liblzma-dev之后重新编译。这个问题的隐蔽点在于python -V不会报错，业务代码不调用这些模块也发现不了异常，往往是上线跑了一段时间才暴露。所以我在前面专门写了一个验证脚本，建议在安装完成后立刻跑一遍，不要等到崩溃才排查。
5.3 现象：pip freeze 生成的 requirements 在 Windows 上装不了
在一台 Windows 机器上pip freeze > requirements.txt，拿到另一台 Linux 服务器上pip install -r requirements.txt，报错说找不到某个版本的包。这个问题的根源不是包不存在，而是pip freeze会把当前平台特有的预编译包版本号固化进去。
比如 Windows 上某些包带win_amd64标记，Linux 环境没有对应 wheel 包，pip 只能尝试从源码编译，而源码编译又需要额外的系统依赖，失败在所难免。我的做法是跨平台迁移时，只把直接依赖写入 requirements，不依赖pip freeze的完整输出；或者干脆用 Conda 的conda env export来锁定跨平台环境，它的处理方式在这方面更成熟。
5.4 现象：pyenv 安装卡在编译阶段超过 20 分钟
运行pyenv install 3.7.17后，编译进度条长时间不动，最后报错说内存不足或者编译超时。原因很简单：编译 Python 需要的内存和 CPU 比想象中多，尤其在配置较低的机器或者内存受限的容器里。
解决办法有两个方向：一是临时增加编译并行度，让编译跑得快点；二是检查系统真实的内存限制。
# 用 2 个并行编译任务加快速度 MAKEOPTS="-j2" pyenv install 3.7.17 # 或先释放内存再编译一个加并行度的潜在风险是内存占用更高，如果机器本身只有 2G 内存，开-j4反而更容易被系统杀掉。先看内存再定并行度，这是经验之谈。
5.5 现象：装完后 python 命令还是旧版本
在已经安装了 Python 3.8 的机器上装 3.7，装完执行python -V显示的还是 3.8，让人误以为安装失败。这其实是 PATH 搜索顺序的问题：系统在 PATH 中先找到了旧版本的可执行文件，新装的 3.7 在后面。
处理方式之一是直接使用完整路径或者py启动器来指定版本。在 Windows 上py -3.7会强制使用 3.7；在 Linux 上用/usr/local/bin/python3.7这样的绝对路径。另一种方式是修改 PATH 顺序，但我觉得这容易引发其他命令的连锁问题，不如在项目脚本里显式指定解释器路径来得可靠。
6. 进阶：用一个可复现脚本把 3.7 环境一次装到位
如果你需要在多台机器上重复搭建 Python 3.7 环境，手工一步步操作既容易遗漏又很难追溯。我通常会把整个过程写成一个脚本，包含依赖安装、版本编译、环境校验三个步骤。这样每次换机器或者重建环境，执行一次脚本就能得到一致的运行时。
#!/usr/bin/env bash set -euo pipefail # 1. 安装系统依赖（Debian/Ubuntu 系） sudo apt update sudo apt install -y make build-essential libssl-dev zlib1g-dev \ libbz2-dev libreadline-dev libsqlite3-dev \ wget curl llvm libncurses5-dev libffi-dev # 2. 用 pyenv 安装指定版本 if ! pyenv --version >/dev/null 2>&1; then curl https://pyenv.run | bash fi pyenv install -s 3.7.17 pyenv global 3.7.17 # 3. 校验标准库完整性 python - <<'EOF' import sys, ssl, sqlite3, bz2, lzma assert sys.version_info[:2] == (3, 7) assert ssl.OPENSSL_VERSION assert sqlite3.sqlite_version assert bz2.__name__ assert lzma.__name__ print("Python 3.7 environment is ready.") EOF这个脚本的核心价值在于可重复执行。pyenv install -s里的-s表示如果版本已安装则跳过，不会重复编译；pyenv global只是把默认版本切换过去，不
本文还有配套的精品资源，点击获取
