Python与orjson性能对比测试

本文深入剖析了orjson与Python标准json库在真实业务场景下的性能差异与兼容性陷阱：虽然orjson在处理含大量浮点数、嵌套列表或datetime的复杂数据时，序列化快2–5倍、反序列化快1.5–3倍，但其优势高度依赖数据结构，对小字典或纯字符串几乎无提升；更关键的是，它不支持default回调、强制输入输出为bytes、缺乏indent/sort_keys等调试功能，且存在大整数精度丢失、类型严格校验等易踩坑细节——盲目替换json.loads/dumps可能引发静默错误或运行时崩溃；文章还指出FastAPI已默认集成orjson（仅限自动响应路径），并强调可靠基准测试必须控制GC、预热、选项配置（如OPT_STRICT_INTEGER）及真实数据样本，避免被缓存或外围IO掩盖真正瓶颈。

orjson 比 json 快多少？别信宣传页，看真实场景

在多数实际场景下，orjson 序列化比标准 json 快 2–5 倍，反序列化快 1.5–3 倍；但这个差距高度依赖数据结构——纯字符串或小字典几乎没差别，而含大量 float、嵌套 list 或 datetime 的 payload 才明显拉开距离。

• 测试时务必用你的真实数据样本，比如从数据库查出的 10k 条记录 dump 出来的 dict list，而不是 {'a': 1, 'b': [1,2,3]} 这种玩具数据
• orjson 不支持 default 回调函数，遇到自定义类型（如 dataclass、UUID）会直接抛 TypeError: Type is not JSON serializable
• 它默认输出 bytes 而非 str，如果后续要拼接 URL 或写日志，得显式调用 .decode()，否则容易踩 TypeError: expected str, bytes found

怎么安全替换项目里的 json.loads / json.dumps？

不能全局搜索替换，因为 orjson 的行为和接口有关键差异，硬切会导致运行时错误或静默数据丢失。

• orjson.loads() 不接受 object_hook 或 parse_float 等参数，如果你靠 object_hook 把 JSON 字段转成 Decimal，就得改用预处理或后解析方式
• orjson.dumps() 默认不带缩进、不排序 key、不处理 NaN/Infinity（会报错），而 json.dumps(indent=2, sort_keys=True) 这类调试友好配置它根本不支持
• 它强制要求输入是 UTF-8 兼容对象，传入 bytes 会报 TypeError: expected str, bytes found；反过来，orjson.loads() 只接受 bytes 或 bytearray，传 str 会直接崩溃

orjson 在 FastAPI / Uvicorn 里要不要手动启用？

FastAPI 从 v0.95.0 起已默认用 orjson 替代 json 做响应序列化，但仅限于 return dict/list 的路径；如果你手动调用 json.dumps() 构造响应体，或用了 Response(content=...)，那还是走标准库。

• 检查是否生效：启动服务后访问一个返回 JSON 的接口，用 curl -v 看响应头里有没有 content-type: application/json，再对比响应体里浮点数是不是没尾随零（orjson 默认省略）、None 是不是变成 null（它严格遵循 JSON 规范）
• 禁用方法是设 app = FastAPI(json_loads=json.loads, json_dumps=json.dumps)，但除非你依赖 default 回调，否则没必要退回去
• Uvicorn 本身不干预 JSON 处理，它只管把 ASGI app 返回的 bytes 发出去，所以“启用 orjson”这事跟 Uvicorn 配置无关

基准测试时最容易漏掉的三个条件

很多人的 benchmark 结果不可复现，问题出在没锁死环境变量和底层行为。

• 必须设置 ORJSON_OPTIONS = orjson.OPT_STRICT_INTEGER（如果数据里有大整数），否则 orjson 可能悄悄把超过 2**53 的 int 转成 float，导致精度丢失——这在金融或 ID 场景里是致命 bug
• 测试前加 import gc; gc.collect()，否则内存缓存会让第二次以后的 orjson.dumps() 显著变快，扭曲真实 IO-bound 场景
• 用 timeit 时避免把 import 写进 setup 字符串，应提前 import，否则每次循环都重载模块，测的其实是导入开销而非序列化本身

真正卡顿的地方往往不在序列化本身，而在你把 orjson.dumps() 的结果又喂给 gzip.compress() 或塞进 asyncpg 的 execute()——这些环节的瓶颈会掩盖 JSON 库差异。先确认 profile 里 json 确实是热点，再动它。

以上就是《Python与orjson性能对比测试》的详细内容，更多关于的资料请关注golang学习网公众号！