JSON慢？不是它不行，是咱用错了地方。

　　最近在公司搞接口优化，发现同样的数据，用JSON传，服务就卡；换种方式，立马顺滑。查了一圈，根本不是JSON本身有问题，而是我们天天把它当万能胶水，什么活儿都让它干。

　　以前总觉得JSON写起来方便，前后端一商量，字段名敲完就能跑。结果上线后P99延迟老超50ms，查下来一半时间耗在解析上。Python里用`json.loads()`读个2KB的订单数据，要3.2毫秒；隔壁组用`ijson`流式读，只要1.1毫秒。差别不是语法，是动作——一个把整段字全吞进去再嚼，一个边读边吐，不存多余东西。

　　还有人爱嵌套，`{"user":{"profile":{"contact":{"email":"a@b.com"}}}}`，写起来像写小说，解析起来像翻五层抽屉。ARM服务器上测过，嵌套超5层，CPU缓存反复换页，多花快四成时间。改成`{"user_profile_contact_email":"a@b.com"}`，体积没大变，但Android手机上解析快了一半还多。

　　数据库里存JSON也容易踩坑。MySQL里直接`JSON_EXTRACT(data, '$.status')`查状态，看着简洁，实际每次都是全表扫。后来加了个虚拟列+普通索引，原来要8秒的报表查询，变成60毫秒出结果。技术没变，只是换了个姿势用。

　　最坑的是把图片Base64塞进JSON。一次上传头像，JSON体直接膨胀到1.3MB，移动端频繁OOM。后来拆开：接口只返回`{ "avatar_url": "/api/img/xxx" }`，图片走独立HTTP链接。错误日志里“JSON decode error”那行，直接少了18%。

　　优化其实不用改架构。键名缩两个字，`usr_name`代替`user_name`，文档里写清楚映射就行；空格全去掉，少传几百字节；Swagger里把缩写表挂上，前端照着生成TS类型，没人看不懂。这些事，今天下午就能干完。

　　真到了非换不可的时候，也别一上来就推倒重来。我们组先在新内部服务上试Protobuf，老接口照旧，网关自动转格式。灰度推了三周，只切1%流量，盯着监控看错误率和延迟。没问题了，再加10%，一点一点挪过去。

　　有人问为啥不全换成MessagePack？它小、快、不用写Schema，但出问题时根本看不出里面存的是啥。调试要装`mpack`工具解码，前端连个`console.log`都打不出结构，对新手太不友好。BSON也是，MongoDB里顺手，但HTTP接口得包一层，多一层封装就多一层隐患。

　　Avro适合大数据管道，Kafka里跑日志，Schema Registry能管版本升级，但搭一套要配ZooKeeper或Confluent，小团队光配环境就得两天。我们当时算了笔账：JSON优化省下的200核小时CPU，够买半年云服务；而换Avro，光学习加迁移，人头时间成本翻倍。

　　最后发现，90%的“JSON慢”，只是没流式读、没扁平化、没缓存校验。剩下10%，才是格式的事。工程师不是比谁用的技术新，是看谁把老技术用得明白。

　　别神话JSON，也别妖魔化它。它就是个文本容器，像塑料袋——装零食挺好，装一桶水就漏。用对了场合，它比啥都省事。

　　x，JSON不是慢，是被当万能胶水乱贴，你真知道它在哪儿卡住吗？