选择 CentOS 上的 Python 安装版本
一 核心原则
- 不删除、不覆盖系统自带的 Python。在 CentOS 7 上，yum 依赖 Python 2.7；在 CentOS 8 上，dnf 依赖 Python 3.6。强行改动系统默认解释器会导致包管理器等核心工具失效。所有自定义版本应以并行方式安装，通过明确的命令如 python3、pip3 调用。
- 以项目需求为最高优先级：框架/库的最低版本要求 > 企业/合规策略 > 运维可维护性。
- 优先选择仍在维护的版本，避免已知安全与兼容风险。
二 版本选择快速建议
| 场景 |
推荐版本 |
主要理由 |
安装方式建议 |
| 新项目，追求长期维护与生态兼容 |
Python 3.11 LTS 或 3.12 LTS |
仍在维护，性能与生态良好，适合新项目 |
源码编译或 pyenv（便于多版本管理） |
| 老项目，依赖较旧库 |
Python 3.8 / 3.9 |
许多旧轮子与新版本存在兼容问题，3.8/3.9 更稳妥 |
系统仓库或源码编译 |
| 仅需快速跑脚本，稳定性优先 |
CentOS 7：3.6（EPEL）；CentOS 8：3.9（AppStream） |
仓库可用、依赖处理简单、系统影响最小 |
yum/dnf 直接安装 |
| 需要同时维护多个项目 |
组合使用 3.8/3.9/3.11/3.12 |
项目隔离、互不干扰 |
pyenv + venv 按项目切换 |
说明：仓库可用版本与系统版本强相关，例如 CentOS 7 通过 EPEL 通常最高到 3.6，CentOS 8 仓库常见到 3.9；若需 3.10+，一般需启用额外仓库或源码编译。
三 按 CentOS 版本给出选择
- CentOS 7
- 现状：系统自带 Python 2.7；EPEL 提供 Python 3.6。
- 选择：新项目优先 3.11/3.12；老项目优先 3.8/3.9；若只求稳定省心，用 3.6。
- 方式：3.6 走 yum；3.8/3.9/3.11/3.12 走源码编译或 pyenv。
- CentOS 8
- 现状：仓库常见 Python 3.9；如需 3.10+，检查额外仓库或源码编译。
- 选择：新项目 3.11/3.12；老项目 3.9/3.8；追求省心用 3.9。
- 方式：3.9 走 dnf；更高版本走源码编译或 pyenv。
- CentOS Stream 8/9
- 现状：AppStream 通常提供多个 python3.x 版本（如 3.9/3.11 等，视仓库而定）。
- 选择：优先使用仓库提供的次新 LTS 版本（如 3.11），新项目可用 3.12（若仓库提供）。
- 方式：优先 dnf 安装对应 python3.x 与 python3.x-pip；若需更细粒度控制，再考虑源码或 pyenv。
四 安装与切换策略
- 并行安装，避免替换系统 Python：源码编译时使用 make altinstall，或用 pyenv 在用户目录管理多版本，避免影响系统工具链。
- 正确调用与切换：使用 python3.x / pip3.x 明确版本；如需设置默认 python3，优先用 alternatives 管理，而不是直接覆盖 /usr/bin/python。
- 依赖与编译：提前安装编译依赖（如 gcc、openssl-devel、bzip2-devel、libffi-devel、zlib-devel 等），否则可能出现 pip 不可用或 SSL 功能缺失等问题。
- 项目级隔离：为每个项目创建 venv（如 python3 -m venv .venv），在虚拟环境内安装依赖，避免跨项目冲突。
- 脚本 shebang：在脚本首行使用解释器的绝对路径（如 #!/usr/bin/python3.11），避免调用到系统 Python。
五 快速决策清单
- 明确项目的最低 Python 版本要求（如框架/库的最低版本）。
- 查看系统版本与仓库可用版本（CentOS 7 常见到 3.6；CentOS 8 常见到 3.9）。
- 若仓库满足：优先 yum/dnf 安装；若不满足：选择 源码编译 或 pyenv。
- 规划多版本需求：用 pyenv 管理；每个项目用 venv 隔离。
- 永远不要替换系统 python；用 alternatives 或显式命令调用目标版本。
