Python 3.15 RISC-V 支持落地后扩展构建要检查哪些假设

Python 3.15 把 RISC-V 纳入 CPython 的 Tier 3 支持后，最容易出现的误判是：解释器能启动，所以第三方扩展也应该能直接安装。实际要分四层看：CPython 运行时是否是 riscv64、扩展 ABI 是否匹配、编译链和系统库是否齐全、目标 wheel 标签是否被 pip 接受。前两层通过，只能说明“可以开始构建”，不能保证“有现成轮子”。

先确认解释器真的运行在 riscv64

交叉编译机、容器和远程构建节点很容易把“目标架构”和“当前执行架构”混在一起。先在目标环境运行下面的检查，尤其记录 sysconfig.get_platform() 与 EXT_SUFFIX，它们比一条版本字符串更接近扩展构建的实际契约。

python3.15 - 

预期至少能看到 machine: riscv64，并且 Python、头文件、编译器来自同一个目标环境。如果机器是 riscv64、解释器却是通过模拟器启动的 x86_64 构建，后面的 native 扩展测试就没有代表性。

Tier 3 支持不等于第三方扩展已有轮子

PEP 11 对 Tier 3 的要求包括可靠 buildbot 和至少一名核心开发者负责，但该平台的失败不阻塞 CPython 发布。这个等级证明的是 CPython 本体有持续维护入口，不会替你解决 NumPy、数据库驱动或自研 C/C++ 扩展的构建与发布。

所以遇到 No matching distribution found，不要立刻判断 Python 3.15 不支持 RISC-V。先查看 pip 当前接受的标签：

python3.15 -m pip debug --verbose
# 重点查看 compatible tags，而不是只看可用版本数量

PyPA 的 manylinux 工具链已经出现 riscv64 镜像，但某个项目是否发布对应 wheel，仍取决于项目自己的 CI、依赖库和索引。能看到 CPython 3.15 与 riscv64 标签，只说明解析器知道这种组合；安装时还要有实际文件。

扩展构建前要把工具链和宿主库对齐

第三方扩展不是只编译一份 Python 代码。C/C++ 扩展通常需要 Python 头文件、编译器、链接器和目标架构的宿主库；Rust 扩展还要检查 Rust target、链接器以及依赖 crate 是否能为 riscv64 生成代码。不要用 x86_64 的开发包去“补齐”一个 riscv64 环境。

如果项目使用 pyproject.toml，先在干净虚拟环境中安装构建后端，再观察失败发生在准备依赖、编译还是链接阶段。Python 3.15 文档也提醒，扩展模块的构建与分发通常交给 setuptools、meson-python 等第三方工具；解释器本身不替你选择这些工具。

python3.15 -m venv .venv
# 让构建依赖只进入本次实验环境
. .venv/bin/activate
python -m pip install -U pip
python -m pip install -v .
# 失败时先区分缺头文件、找不到库和链接器架构错误

若扩展使用 CPython 3.15 新增的导出钩子，必须确认源码和构建后端都按目标 Python 版本处理；若要兼容更早版本，则不能把只在 3.15 存在的 API 当成通用 ABI。稳定 ABI、自由线程 ABI 和普通 CPython ABI 也要在发布矩阵中分开记录。

最后用可安装性和导入测试收口

构建成功也只说明产物生成了。发布前至少记录 wheel 文件名、Python/ABI/平台标签、构建镜像或系统版本，并在目标 riscv64 环境执行一次干净安装和导入。带原生依赖的包还要调用一个最小功能，而不是只执行 import。

python3.15 -m pip install --no-index --find-links dist your-package
python3.15 - 

这套检查能把问题分成三类：解释器或 ABI 不匹配、wheel 标签不匹配、以及链接到错误架构的系统库。部署到 CI 时，把 riscv64 原生 runner 或可复现的交叉构建镜像写进矩阵，不要只在 x86_64 上生成一个“看起来通用”的 wheel。

常见问题

Python 3.15 支持 RISC-V 后，所有 PyPI 包都会自动可装吗？

不会。CPython 支持和每个项目的 wheel 发布矩阵是两件事。没有匹配 wheel 时仍可能需要源码构建，或者等待项目提供 riscv64 产物。

为什么 platform.machine() 正确，扩展还是导入失败？

它只反映当前机器识别到的架构，不能证明扩展文件、Python ABI、glibc 或链接到的宿主库都匹配。继续检查 wheel 标签、EXT_SUFFIX 和动态依赖。

可以先在 x86_64 编译，再复制到 RISC-V 吗？

纯 Python 文件通常可以，含本地二进制的扩展不应这样做。除非使用明确配置的交叉工具链并在真实 riscv64 环境完成导入和功能测试，否则应视为未验证。