登录
首页 >  文章 >  python教程

Python序列化工具对比:orjsonvsujsonvsrapidjson

时间:2026-03-07 15:27:45 226浏览 收藏

本文深入对比了 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

如果你只序列化标准类型(dictliststrintfloatboolNone),orjson 通常是最快的——它用 Rust 写的,直接输出 UTF-8 bytes,跳过 decode/encode 步骤。但一旦要序列化 datetimeDecimaldataclass 或自定义对象,它就直接报 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)、defaultobject_hooknumber_mode 等高级选项,甚至能开 SIMD 加速。但它编译耗时长,wheel 包体积是 orjson 的 5 倍以上,CI 构建时间明显增加。

实操建议:

  • 需要序列化 float('inf') 或控制浮点精度(如 number_mode=rapidjson.NM_DECIMAL)时,它是唯一选择
  • Docker 构建中加 CACHE FROM 缓存 rapidjson 层,否则每次重装很拖节奏
  • 注意它默认把 floatdouble 处理,某些金融场景下可能丢失精度,得显式配 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学习网公众号!

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>