Python 3.15 venv 的 platlib 路径怎么验收：sys.platlibdir、lib64 与旧环境迁移

如果旧部署脚本默认寻找 venv/lib/python3.15/site-packages，迁移到 Fedora、SUSE 一类把平台库放在 lib64 的 POSIX 主机时，最容易误判的是“路径变了，所以整个虚拟环境不能用了”。Python 3.15 的实际变化更窄：创建 venv 时，平台相关库目录会按需创建，不再依赖 lib64 -> lib 符号链接；纯 Python 包和平台相关包的落点要分别验收。

验收时不要猜目录名：先看 sys.platlibdir 判断平台库语义，再用 sysconfig.get_path("platlib") 与 get_path("purelib") 读取当前 venv 的真实安装位置。旧 venv 不要整体搬运，目标主机重新创建并复查写死的路径。

先把 platlib、purelib 和 sys.platlibdir 对上号

在 Python 3.15 venv 中，platlib 与 purelib 都属于安装方案中的第三方目录，但职责不同：前者放平台相关文件，例如需要匹配 CPU 或操作系统的扩展模块；后者放纯 Python 模块。sys.platlibdir 描述的是平台相关库目录名，官方文档给出的常见值是大多数平台的 lib，以及 Fedora、SUSE 64 位系统上的 lib64。

关键点在于目录名和安装角色不是一回事。Python 3.15 的变更说明指出，POSIX 创建虚拟环境时如果需要，会直接创建 platlib 目录，替代过去的 lib64 -> lib 链接。因此检查脚本不能只判断某个符号链接是否存在。

用 Python 3.15 创建一个可复查的 venv

先在目标 POSIX 主机用目标解释器创建环境：

python3.15 -m venv .venv
.venv/bin/python -c 'import sys; print(sys.version); print(sys.prefix); print(sys.base_prefix)'

目录观察点固定为 .venv/bin、.venv/pyvenv.cfg 和第三方包目录。pyvenv.cfg 中的 home 表明创建环境所用的基础 Python，include-system-site-packages 表明是否显式打开系统包访问。验证虚拟环境时，sys.prefix != sys.base_prefix 是比检查环境变量更可靠的判断。

环境本身是可丢弃的部署产物，不要把项目源码放进去，也不要把旧目录打包后直接解压到新主机。记录解释器版本和依赖声明，迁移时用同一套依赖输入重建，排查范围会小得多。

用 sysconfig 验收 platlib 与 purelib 的真实落点

目录名只能提供线索，最终以当前解释器的安装方案为准。下面的检查只读取标准库配置，不需要安装第三方包：

import sys
import sysconfig

print("platlibdir:", sys.platlibdir)
for name in ("platlib", "purelib", "scripts"):
    print(name, "=>", sysconfig.get_path(name))
print("scheme:", sysconfig.get_default_scheme())

在虚拟环境中，sysconfig 提供 posix_venv 方案，默认情况下它与 POSIX 前缀方案的路径规则一致。对照输出时重点看三件事：路径是否位于当前 sys.prefix 下，版本目录是否对应当前解释器，以及 platlib、purelib 是否在该发行版上分离。

这里不要把 sys.platlibdir 直接拼到所有包路径上。官方路径表明确区分了纯 Python 的 purelib 和平台相关的 platlib；安装器应使用标准安装方案，而不是依赖某个发行版当前恰好提供的符号链接。

旧环境迁移时只修路径假设，不搬运整个目录

把旧脚本逐项过一遍，搜索硬编码的 /lib/pythonX.Y、/lib64/pythonX.Y、site-packages 和环境绝对路径。能改成“调用当前解释器查询”的地方，就不要写死发行版目录；例如部署检查用 .venv/bin/python -m pip，路径检查用 sysconfig.get_path。

迁移决策可以按下面的顺序落地：

1. 保存项目的依赖输入、Python 主次版本和目标平台信息。
2. 在目标位置重新执行 python3.15 -m venv .venv，读取新的 pyvenv.cfg。
3. 用 sys.platlibdir、platlib、purelib 三组值更新检查脚本。
4. 重新安装依赖并验证导入；不要以旧的 lib64 -> lib 链接是否存在作为唯一成功条件。

如果扩展模块加载失败，先确认它实际进入的是当前解释器返回的 platlib，再检查架构、构建标签和依赖库。若只是纯 Python 包找不到，优先核对 purelib、sys.path 与启动解释器是否来自同一个 venv。

相关问题

Python 3.15 的 venv 一定会出现 lib64 目录吗？

不一定。目录由平台安装方案和是否需要平台相关库决定；Python 3.15 的变化是按需创建 platlib，而不是保证每个环境都固定出现 lib64。

platlib 和 purelib 在所有 Linux 发行版上都不同吗？

不一定。许多平台会让两者落在同一个 site-packages 目录，是否分离应以当前解释器的 sysconfig 返回值为准。

旧 venv 可以直接复制到新服务器吗？

不建议。官方 venv 文档把虚拟环境视为可重建、不可移动的目录；应在目标位置重新创建，再按依赖声明恢复。

检查 Python 包安装位置应该优先看哪个接口？

优先看 sysconfig.get_path("platlib") 和 get_path("purelib")，sys.platlibdir 用来解释平台库目录语义，不能替代完整安装方案。