orjson最快但不支持自定义encoder；ujson支持default但python 3.12+有兼容问题；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 都不给。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
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' 这类错误。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 如果项目已用
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 构建时间明显增加。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 需要序列化
float('inf')或控制浮点精度（如number_mode=rapidjson.NM_DECIMAL）时，它是唯一选择 - Docker 构建中加
CACHE FROM缓存rapidjson层，否则每次重装很拖节奏 - 注意它默认把
float当double处理，某些金融场景下可能丢失精度，得显式配NM_DECIMAL
别在日志里无脑换库，先看瓶颈在哪
很多人一看到“更快的 JSON 库”就立刻替换，结果发现 QPS 没涨，CPU 反而更抖——因为实际瓶颈常在 I/O（如写磁盘、发 HTTP）或业务逻辑，不是 dumps() 那几微秒。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
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() 就静默失败。这种地方，库选型反而不如协议约定重要。
