CPython 核心开发团队已经正式认可 RISC-V 为 Tier 3 平台。这不是“所有功能都已经和主流平台完全一致”，而是 RISC-V 支持获得了明确的平台级定位：实现已经经过社区持续协作，接下来需要更多真实硬件、持续测试和性能反馈来推动集成度提升，并为未来迈向 Tier 2 做准备。
对于使用 RISC-V 开发板、服务器或模拟环境的 Python 开发者来说，现在最有价值的工作并不是简单地宣布“能启动 Python”，而是把版本、架构、测试结果和异常表现反馈给 CPython 社区。
Tier 3 对实际开发意味着什么
平台分级通常反映的是维护承诺、测试覆盖和发布信心，而不只是“能不能编译”。RISC-V 被列为 Tier 3，至少说明它已经进入 CPython 官方平台支持的讨论范围，并且有持续的社区实现工作作为基础。
但开发团队仍然需要关注几个边界：
- 某些版本或构建配置可能仍需要平台相关修复。
- 持续集成中的测试覆盖仍有提升空间。
- 不同 RISC-V 芯片、发行版和 ABI 配置可能表现不同。
- 性能问题不能只通过功能测试发现，必须在真实硬件上采样和比较。
因此，项目团队不应把 Tier 3 理解成与 Tier 1 平台相同的兼容性承诺。更稳妥的做法是把 RISC-V 构建纳入自己的兼容性矩阵，并明确记录硬件型号、操作系统、工具链和 CPython 版本。
先建立一份可复现的平台报告
在 RISC-V 机器上，下面的命令可以收集一份最小环境信息。它不修改系统，适合在提交 issue、测试报告或内部兼容性记录中使用。
#!/usr/bin/env bash
set -eu
echo "== kernel =="
uname -a
echo "== architecture =="
uname -m
echo "== libc =="
ldd --version 2>&1 | head -n 1 || true
echo "== compiler =="
cc --version 2>&1 | head -n 1 || true
echo "== Python =="
python3 --version
python3 - <<'PY'
import platform
import sys
print("sys.version:", sys.version.replace("\\n", " "))
print("machine:", platform.machine())
print("implementation:", platform.python_implementation())
print("executable:", sys.executable)
print("cache_tag:", getattr(sys.implementation, "cache_tag", "unknown"))
PY
把脚本保存为 report-riscv.sh 后运行：
chmod +x report-riscv.sh
./report-riscv.sh | tee riscv-cpython-environment.txt
这份输出尤其适合与测试失败日志一起保存。仅记录 riscv64 还不够，因为发行版、C 库、编译器版本和 CPython 构建选项都可能影响结果。
在 RISC-V 主机上从源码构建并运行测试
如果设备已经具备 Git、C 编译器、Make 和 CPython 构建所需的系统依赖，可以用下面的流程验证源码构建。命令中的安装目录可以按团队规范调整；示例默认安装到用户目录，避免覆盖系统 Python。
git clone --depth 1 https://github.com/python/cpython.git
cd cpython
./configure --prefix="$HOME/.local/cpython-riscv"
make -j"$(nproc)"
make test
make install
"$HOME/.local/cpython-riscv/bin/python3" --version
"$HOME/.local/cpython-riscv/bin/python3" -m test.regrtest -j0 test_json test_threading
这组命令适合做初步验证，但不能替代完整的 CPython 测试流程。对于资源有限的开发板，可以先运行少量回归测试，再逐步扩大范围；对于服务器或 CI 节点，则应记录完整测试耗时、失败用例和是否发生超时。
如果构建失败，反馈信息至少应包含：
uname -a和uname -m的输出。- RISC-V 芯片或虚拟机配置。
- Linux 发行版、C 库和编译器版本。
- CPython 提交版本或发布版本。
configure参数、失败阶段和完整错误日志。- 问题是否只出现在特定优化选项或并行度下。
从“能运行”走向“可维护”
RISC-V 支持要进一步提升，持续测试会比一次性的成功构建更重要。团队可以从三个层面参与：
把真实硬件加入测试矩阵
模拟器适合快速验证编译和基础功能，但真实硬件更容易暴露内存带宽、线程调度、I/O 和指令扩展方面的问题。即使暂时不能提供公共 CI 节点，也可以定期运行 CPython 测试并公开结果。
用小型基准识别性能回归
可以选择启动时间、JSON 编解码、线程调度和常用库导入等场景，固定输入与运行次数，比较不同 CPython 构建和不同 RISC-V 设备的结果。基准数据应标注硬件和工具链，否则跨平台比较很容易得出错误结论。
提交可定位的反馈
“Python 很慢”很难帮助维护者定位问题；“CPython 某提交在某型号 RISC-V 设备上运行 test_json 时失败，使用某编译器和某优化参数”则更有价值。稳定性问题、测试缺口和性能差异都值得反馈，因为这些信息会直接影响后续的持续集成工作。
采用建议：把 RISC-V 当作需要验证的平台
如果你的产品已经部署在 RISC-V 上，可以现在就做一份兼容性清单：
- 固定 CPython 版本和构建方式。
- 保存架构、ABI、发行版与工具链信息。
- 在发布前运行一组稳定的回归测试。
- 为失败用例保留完整日志，而不是只记录退出码。
- 将性能基线和功能测试分开维护。
- 发现问题时优先提交可复现步骤。
Tier 3 是一个重要的官方里程碑，但它更像是协作的起点，而不是终点。对 RISC-V 用户而言，最实际的贡献就是在真实环境中持续运行、测量并反馈；这些具体数据，才可能帮助 CPython 逐步提高测试覆盖和平台稳定性，并向 Tier 2 支持迈进。