# 深入理解Python simplejson一个被低估的JSON处理利器几年前当我在处理一个日均请求量过百万的API服务时遇到过一个让人抓狂的问题标准库json模块在处理某些特殊字符时会不声不响地把数据搞坏。那次经历让我第一次把目光投向了simplejson并从此成了它的忠实用户。很多人觉得JSON解析不就是那点事吗但当你真正踩过坑才会明白这个看似简单的格式背后有多少细节。什么是simplejsonsimplejson本质上是一个用纯Python编写的JSON编码解码库它的代码库比标准库的json模块要早出生好几年。如果你去翻它的源码会发现它其实很轻量核心文件就那么几个。但它不是标准库的替代品那么简单——它提供了很多标准库没有的“开关”让开发者能精细控制JSON处理的行为。有意思的是Python 2.6版本的标准库json模块其实就是直接复制了simplejson的代码。虽然后来两者各自进化但血缘关系摆在那里。现在你看到的json模块很多接口设计都留有simplejson的影子。它能做什么以及为什么值得用先说最简单的读写JSON字符串序列化dict、list这些基本操作这些它都能做就像标准库一样。但真正让它出彩的地方是它提供了一堆细粒度控制选项。举个例子假设你在处理前端传过来的数据里面可能有NaN或Infinity这样的特殊浮点值。标准库json碰到这些值默认会直接抛出异常。但simplejson可以配置allow_nanFalse来决定是否接受或者用parse_float参数自定义解析逻辑。这在处理一些非标准但实际存在的JSON变体时特别有用。还有一个很实用的场景当你需要序列化datetime对象时。标准库要求你写一个自定义encoder但simplejson可以通过default参数更优雅地处理配合use_decimal参数还能精确控制数字精度。做金融系统的朋友应该深有体会浮点数的精度问题在JSON序列化过程中有多坑。怎么用起来安装就是最简单的pip install simplejson。但这里有个小细节在CPython环境下simplejson会自动尝试用C扩展来加速如果编译失败就fallback到纯Python实现。所以如果你在部署时发现性能不如预期先检查下C扩展是不是被正确编译了。最基本的用法和json模块一模一样importsimplejsonasjson data{name:张三,scores:[95.5,88.2]}json_strjson.dumps(data,ensure_asciiFalse,indent2)但你可能想试试这些真正实用的参数# 处理特殊数值json.dumps(float(nan),allow_nanFalse)# 会抛出异常json.dumps(float(nan),allow_nanTrue)# 输出NaN# 精确控制浮点数精度fromdecimalimportDecimal data{price:Decimal(19.99)}json.dumps(data,use_decimalTrue)# 输出 19.99 而不是 19.990000000000002# 自定义对象序列化fromdatetimeimportdatetimedefdatetime_handler(obj):ifisinstance(obj,datetime):returnobj.isoformat()raiseTypeError json.dumps({time:datetime.now()},defaultdatetime_handler)有个很容易被忽视的函数是simplejson.loads的object_pairs_hook参数。标准库的object_hook只能处理dict而object_pairs_hook能让你以有序键值对的形式解析JSON对象。当你需要保持字段顺序或者处理重复键时这个功能简直就是救星。一些值得注意的最佳实践性能调优虽然在大多数场景下simplejson已经够快但如果你在遍历大量JSON时需要频繁解析可以考虑用raw_decode方法进行流式解析。这比反复调用loads要高效得多因为它能在一个字符串中解析出多个JSON对象。编码问题处理中文或其他非ASCII字符时务必设置ensure_asciiFalse否则所有非ASCII字符都会被转义成\uXXXX的形式。但要注意这会增加输出字符串的体积。对于需要网络传输的场景可以考虑用压缩算法配合。安全方面永远不要用json.loads去解析不可信的JSON字符串除非你明确知道自己在做什么。simplejson提供了一个JSONDecodeError异常类捕获时要精确一些不要简单用except Exception盖住所有错误。版本兼容如果你在写一个会被分发的库强烈建议用条件导入来处理simplejson和json的差异。标准库在Python 3.6之后修复了很多JSON处理的问题但有些边角情况还是simplejson处理得更好。同类技术对比和标准库json的对比是最直接的。两者的API几乎一样但simplejson提供了更多控制参数而且在处理一些极端情况时更稳健。不过标准库经过多年优化在纯Python实现的性能上已经和simplejson不相上下。选择simplejson的主要理由应该是它那些额外的功能特性而不是纯粹的性能考虑。另一个不得不提的是orjson。这个用Rust写的库在性能上有绝对优势比simplejson快3-5倍。但它的代价是需要C扩展在某些环境下部署会麻烦一些。而且orjson的API和标准库差异较大迁移成本相对较高。如果你追求极致性能orjson是更好的选择如果需要在不同Python版本和环境之间无缝切换simplejson更稳妥。还有个叫ujson的库曾经很流行但现在基本已经停止维护了。它的问题是对Unicode的支持不够好在处理中文时偶尔会出bug。所以除非你维护的是遗留项目否则不建议用了。说到底选择哪个JSON库要看具体场景。我自己日常开发倾向于用simplejson因为它提供了恰到好处的控制力又不会像orjson那样增加部署复杂度。但在写高性能中间件或处理海量数据时我还是会切换到orjson。工具这东西没有绝对的好坏只有适不适合。记得有一次一个同事在Stack Overflow上看到有人抱怨simplejson的文档不够详细但其实它的源码注释写得很好。很多时候直接去看源码反而能获得比文档更准确的理解。毕竟再好的文档也赶不上代码本身来得直接。