当前位置：首页 > 文章列表 > 文章 > python教程 > Python序列化工具对比：orjsonvsujsonvsrapidjson

Python序列化工具对比：orjsonvsujsonvsrapidjson

2026-03-07 15:27:45 0浏览收藏

本文深入对比了 Python 三大高性能 JSON 库——orjson、ujson 和 rapidjson的核心差异：orjson 以 Rust 实现，序列化标准类型最快但完全不支持自定义 encoder，返回 bytes 易引发编码误用；ujson 兼具速度与 default 回调灵活性，却在 Python 3.12+ 面临兼容风险且解析容错性过强可能掩盖数据问题；rapidjson 功能最完备、支持 NaN/Infinity 等边缘场景和精细浮点控制，但体积大、编译慢、安装成本高。文章强调选型不能盲目追求“更快”，而应先通过火焰图定位真实瓶颈——多数情况下 I/O 或业务逻辑才是性能关键，JSON 库替换反而徒增复杂度；更务实的策略是按场景混合使用（如高频简单结构用 orjson，低频复杂对象用 rapidjson），并优先统一跨服务的数据契约（如明确 bytes/str 交接规范），而非强求库的一致性。

Python orjson + ujson + rapidjson 的序列化选型

orjson 比 ujson 快，但不支持自定义 encoder

如果你只序列化标准类型（dict、list、str、int、float、bool、None），orjson 通常是最快的——它用 Rust 写的，直接输出 UTF-8 bytes，跳过 decode/encode 步骤。但一旦要序列化 datetime、Decimal、dataclass 或自定义对象，它就直接报 TypeError: Type is not JSON serializable，连 fallback 都不给。

实操建议：

orjson.dumps() 返回 bytes，不是 str，别直接拼进日志或 HTTP 响应体里（除非你确认接收方能吃 bytes）
想兼容 datetime？得自己先转成 ISO 字符串：orjson.dumps({'ts': dt.isoformat()})
不能传 default=... 参数，这是硬限制，不是配置漏了

ujson 支持 default 函数，但 Python 3.12+ 有兼容性问题

ujson 是 C 实现，速度比标准库快，也支持 default 参数，适合需要轻量定制序列化的场景。但它在 Python 3.12+ 上还没完全适配：部分构建环境会因 PyO3 或 ABI 变更失败，CI 里常见 ImportError: cannot import name 'JSONDecodeError' from 'ujson' 这类错误。

实操建议：

如果项目已用 default 处理 datetime，且没升级到 3.12，ujson 是稳妥选择
升级 Python 后务必跑一遍 import ujson; ujson.dumps({})，别等上线才暴露
ujson.loads() 对非法 JSON 更宽容（比如尾部逗号），线上服务若依赖严格校验，反而可能埋雷

rapidjson 功能最全，但体积大、安装慢

rapidjson 是 C++ 实现，支持完整 JSON 规范（包括 NaN、Infinity）、default、object_hook、number_mode 等高级选项，甚至能开 SIMD 加速。但它编译耗时长，wheel 包体积是 orjson 的 5 倍以上，CI 构建时间明显增加。

实操建议：

需要序列化 float('inf') 或控制浮点精度（如 number_mode=rapidjson.NM_DECIMAL）时，它是唯一选择
Docker 构建中加 CACHE FROM 缓存 rapidjson 层，否则每次重装很拖节奏
注意它默认把 float 当 double 处理，某些金融场景下可能丢失精度，得显式配 NM_DECIMAL

别在日志里无脑换库，先看瓶颈在哪

很多人一看到“更快的 JSON 库”就立刻替换，结果发现 QPS 没涨，CPU 反而更抖——因为实际瓶颈常在 I/O（如写磁盘、发 HTTP）或业务逻辑，不是 dumps() 那几微秒。

实操建议：

用 py-spy record -o profile.svg --pid $PID 抓真实火焰图，确认 json.dumps 是否真占 Top 3
如果只是日志格式化（比如 json.dumps({'msg': ..., 'ts': ...})），用 orjson + 预格式化字段更省事，别碰 default
混合使用没问题：高频简单结构走 orjson，低频复杂对象走 rapidjson，没必要强求统一

真正麻烦的是跨服务数据契约——比如 A 服务用 orjson 输出 bytes，B 服务用 json.loads() 读 str，中间少了 .decode() 就静默失败。这种地方，库选型反而不如协议约定重要。

以上就是《Python序列化工具对比：orjsonvsujsonvsrapidjson》的详细内容，更多关于的资料请关注golang学习网公众号！