Python 3.14 导入 jsonschema 段错误，检查旧 rpds-py 扩展

升级 Python 后，import jsonschema 直接让进程段错误退出，Python 栈停在 _typed_map_converter，C 栈又进入 rpds 的扩展模块时，先检查 rpds-py 的实际安装版本与构建来源。还没开始校验业务 schema，故障就已经发生，修改 schema 内容通常触发不到这一层问题。

这条明确出现过的组合是 Python 3.14、jsonschema 4.25.1 与旧的 rpds-py 0.8.10。jsonschema 在建立类型检查表时使用 HashTrieMap.convert()，旧扩展在这条路径发生崩溃。不能据此把所有 Python 3.14 段错误都算成同一个故障。

先读安装信息，避免为了查版本再次导入

在原进程所用的解释器和环境中查看发行信息：

python -m pip show jsonschema rpds-py
python -m pip check

python 应换成应用真正使用的解释器入口。发行包名是 rpds-py，导入模块名则是 rpds，不要因为名称不同漏掉这个依赖。保留已有完整 stderr、退出状态和扩展文件路径，不需要为了得到版本号再执行一次会崩溃的导入。

jsonschema 4.25.1 声明的下界还是 rpds-py>=0.7.1，因此旧组合可能通过依赖约束检查。pip check 判断的是已声明的依赖关系，不能证明某个历史二进制扩展兼容新的 CPython 运行时。

如果环境由系统包管理器、Nix 或另一套构建工具生成，应检查它实际选用的扩展与构建规则。另开终端安装一个新版包，而应用继续使用旧环境，不会改变加载结果。

在目标解释器环境中选择受支持的扩展

jsonschema 4.26.0 的正式依赖已把下界提高到 rpds-py>=0.25.0。rpds-py 0.25.0 的正式构建使用 PyO3 0.25.0，原故障组合也有更新到这个版本后恢复的明确结果。这说明应处理底层扩展兼容性，不代表永远只固定一个最低版本就足够。

在项目的依赖管理流程里选择支持目标 Python、平台及架构的正式 rpds-py 发行版，同时保留 jsonschema、referencing 等现有约束。当前可用的版本范围还受 Python 版本和发行产物影响；不要把其他机器上的 .so 或 .pyd 直接复制过来，也不要通过强制跳过版本检查让旧扩展继续加载。

需要更新 jsonschema 时，审查它的 Python 下界和其他依赖变化；若暂时保留旧 jsonschema，也应单独约束并核对兼容的 rpds-py。采用目标环境可用的 wheel，或遵守该扩展的正式源码构建要求。只清理 pip 下载缓存，不会自动替换应用环境中已经安装的模块。

先在独立环境按审定锁文件重建，再核对实际包路径。不要在仍服务请求的解释器目录中混合新旧扩展；失败时恢复原解释器与整套已知可用依赖，而不是只把版本文本改回去。

导入恢复后还要校验原任务

确认新环境能够完成导入，再覆盖应用原先使用的 schema 校验和自定义类型检查。特别保留真正调用 HashTrieMap 的类型映射路径，不能只凭一个不经过 jsonschema 的健康检查判断已恢复。

如果依赖和加载路径都已更新，仍然段错误，比较新的 Python 栈和 C 栈。故障已转到其他扩展、栈展开或业务计算时，应另行定位。NumPy 大数组运算中的解释器构建问题，与这里导入阶段的 rpds 扩展兼容路径不同。