orjson在多数实际场景下序列化比json快2–5倍、反序列化快1.5–3倍，但性能差距高度依赖数据结构，纯字符串或小字典差异甚微，而含大量float、嵌套list或datetime的数据才显著拉开距离。
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 结果不可复现，问题出在没锁死环境变量和底层行为。
立即学习“Python免费学习笔记（深入）”；
- 必须设置
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 确实是热点，再动它。
