尧图网页设计 
easy-vibe 序列化原理与实战掌握 JSON、XML、Protobuf、MessagePack 数据翻译全链路【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe序列化Serialization是把内存中的对象翻译成可传输格式、反序列化Deserialization再把传输格式还原成对象的过程是前后端通信、微服务 RPC、分布式缓存与持久化存储共同依赖的基础设施。本文以 easy-vibe 课程仓库docs/de-de/appendix/4-server-and-backend/serialization.md为骨架结合仓库中配套的交互式演示组件与本地化数据系统讲解序列化的必要性、四大主流格式的取舍、跨语言实现对照、性能差异、高频踩坑点与电商级实战方案读完后你将能够依据业务场景独立完成序列化技术选型并落地代码。为什么需要序列化三个必须解决的真实场景前端与后端交互时数据要经过多次变形才能从服务器抵达客户端。以下三个场景直接回答了为什么必须序列化。场景一前端拿到的数据变了样后端发送的是一个日期对象但前端收到的却是一个字符串// 后端发送 Date birth new Date(1990, 5, 15) // 前端接收 { birth: 1990-06-15T00:00:00Z } // 一个字符串前端想调用.getFullYear()却直接报错——因为收到的根本不是Date对象而是字符串。这正是跨语言、跨运行时数据表达不一致的典型后果JavaScript 的Date在 JSON 世界里没有原生对应物只能退化成字符串。场景二中文字符变成乱码// 期望的结果 { name: 张三 } // 实际收到的 { name: å¼ ä¸ }字符编码不一致例如发送端用 UTF-8、接收端按 GBK 解读或反之会把多字节字符拆成错误的字节序列产生不可读的乱码。场景三性能瓶颈// 一次返回 10000 条商品记录的响应 { products: [ { id: 1, name: ..., description: ..., ... }, // ... 其余 9999 条 ] } // 体积5.2 MB传输耗时3.5 秒JSON 文本格式的冗余大量{}、、逗号与字段名重复导致数据包过大严重拖累传输性能。一句话本质序列化就是翻译——把内存对象翻译成可传输格式接收方再把它翻译回来。上述三个场景分别是翻译后含义丢失、翻译时字符表不一致和翻译产物过于臃肿的问题。序列化与反序列化的概念与动机序列化Serialization将对象转换为可传输格式的过程即对象 → 字节流。反序列化Deserialization将传输格式还原为对象的过程即字节流 → 对象。包裹快递类比快递流程序列化环节说明打包物品序列化把物品装进箱子、贴上标签运输网络传输快递车把包裹运到目的地拆箱取物反序列化收件人打开箱子、取出物品类比的关键在于箱子和标签传输格式是标准化的所以无论寄件人发送进程和收件人接收进程使用什么语言、什么平台只要遵循同一套标准就能无损还原。为什么必须有序列化原因说明典型场景网络传输网络只能传输字节流API 调用、RPC 通信持久化存储磁盘只能保存字节对象存入文件或数据库跨语言不同语言的数据结构不同Java 对象 → Python 字典分布式缓存Redis/Memcached 存储字节缓存用户信息从这四类动机可以看出只要存在进程边界网络、磁盘、语言、中间件就必然存在序列化。这也是 easy-vibe 后端基础章节把它列为必学主题的原因——它位于 4-server-and-backend 系列文档 之中与 API 设计、缓存 等主题共同构成后端知识底座。主流序列化格式全景仓库为该主题配套了一个可交互演示组件 SerializationDemo.vue它用内存对象 → JSON 字符串 → 二进制三步动画直观展示序列化全流程并在底部给出格式对比评分表。该组件在 主题组件注册表 与 站点配置 中挂载对应的英文文案与数据定义在 server-backend/en.js。读者在本地运行npm run dev后即可在对应页面点击体验。JSON通用性最强优点可读性好便于调试所有语言都支持浏览器原生支持JSON.parse/JSON.stringify缺点体积大大量{}标记不支持丰富的数据类型Date、Map、Set 会被转成字符串应用场景公共 API、前后端通信、配置文件。XML曾经的主流标准?xml version1.0 encodingUTF-8? user id123/id name张三/name emailzhangsanexample.com/email age28/age /user优点结构清晰支持注释支持复杂嵌套有 Schema 校验XSD缺点体积大、解析慢标签冗余open/open成对出现应用场景配置文件Spring、MyBatis、SOAP 协议、复杂数据交换。Protobuf效率最高// user.proto syntax proto3; message User { int32 id 1; string name 2; string email 3; int32 age 4; }优点体积小比 JSON 小 30%–50%速度快解析速度是 JSON 的 5–10 倍向后兼容新增字段不影响旧版本缺点不可读二进制格式需要.proto定义文件不支持动态类型应用场景微服务内部通信、高性能场景游戏、实时通信、移动端省流量。补充原理Protobuf 之所以小且快关键在于.proto中每个字段的编号 1、 2…会被编码进二进制流作为字段标识因此字段名完全不出现在传输数据中传输字节只包含字段编号、类型标记wire type与值本身。仓库演示数据中给出了一个直观的字节级示例见 server-backend/en.js08 7b # field 1, varint 123 12 05 # field 2, length 5 41 6c 69 63 65 # UTF-8 Alice 1a 11 # field 3, length 17 61 6c 69 63 65 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 20 1c # field 4, varint 28整条User消息只需 38 字节这正是 Protobuf 高压缩比的结构性来源。MessagePack可读性与性能的平衡点// MessagePack 是 JSON 的二进制版本 // 同样数据MessagePack 比 JSON 大约小 30%优点比 JSON 更小、更快保持 JSON 的数据模型支持全部 JSON 类型缺点不可读效率不如 Protobuf应用场景需要性能但不想引入 Protobuf 的场景、Redis 缓存、WebSocket 消息。交互演示与格式对比SerializationDemo.vue 内置 JavaScript / Python / Java / Go 四种语言的演示左侧展示各语言的内存对象代码中间经序列化 → 二进制化两步箭头动画过渡右侧给出二进制十六进制片段与字节数。有意思的是Java 的二进制面板显示的是AC ED 00 05 73 72 ...约 150 字节这正是 Java 原生Serializable序列化的魔数头部AC ED与冗长的类元数据——直观说明语言自带序列化不一定比通用二进制格式高效。演示底部的对比评分表来自 server-backend/en.js从体积、速度、可读性、跨语言四个维度给出星级评价格式体积速度可读性跨语言JSON★★★☆☆★★★☆☆★★★★★★★★★★XML★★☆☆☆★★☆☆☆★★★★★★★★★★Protobuf★★★★★★★★★★★☆☆☆☆★★★★☆MessagePack★★★★☆★★★★☆★★☆☆☆★★★★★各语言序列化方案对照无论你使用哪种后端语言序列化都是日常开发的高频操作。下面是主流语言的常用库速查表语言JSON 库Protobuf 库XML 库JavaScriptJSON.stringify()protobuf.jsfast-xml-parserPythonjson.dumps()protobufxmltodictJavaJackson/Gsonprotobuf-javaJAXBGoencoding/jsonprotoencoding/xmlCnlohmann/jsonprotobuftinyxml2C#System.Text.JsonGoogle.ProtobufSystem.Xml选型建议前后端通信JSON便于调试微服务内部Protobuf性能最佳配置文件JSON 或 YAML对接遗留系统XML可能别无选择值得一提的是仓库演示数据还覆盖了 Go 的gob编码与 Java 原生序列化见 server-backend/en.js可以作为上表的补充视角Go 的gob是一种高效二进制编码但一般只用于 Go 语言内部进程间交换Java 原生序列化虽然零依赖却因携带完整类描述信息而体积偏大且存在安全风险现代 Java 服务更倾向 Jackson/Gson 搭配显式 DTO。性能对比体积与速度数据体积对比以用户对象为例格式体积相对 JSONJSON68 字节100%XML142 字节209%Protobuf38 字节56%MessagePack52 字节76%以上 JSON 68 字节、MessagePack 52 字节、Protobuf 38 字节的数据与演示组件中的jsonSize/binarySize字段完全一致见 server-backend/en.js可作为课程内部基准参考。XML 因成对标签的冗余开销达到 JSON 的两倍以上。速度对比序列化 1 万次格式耗时相对 JSONJSON45 ms100%XML120 ms267%Protobuf8 ms18%MessagePack28 ms62%性能测试结论Protobuf 最快适合高性能场景MessagePack 次之比 JSON 快约 40%JSON 最慢但对大多数场景已经足够需要说明的是这些数字是课程文档中用于横向比较的基准数据实际性能会受数据规模、字段结构、库实现与运行环境影响落地前建议基于自身真实数据做压测验证。常见问题与解决方案日期序列化问题问题Date 对象序列化后变成字符串。// 序列化之前 const date new Date(2024-01-01) // 序列化之后 JSON.stringify(date) // 2024-01-01T00:00:00.000Z解决方案// 方案一转成时间戳 { createdAt: date.getTime() } // 1704067200000 // 方案二转成 ISO 字符串 { createdAt: date.toISOString() } // 2024-01-01T00:00:00.000Z // 方案三自定义序列化利用 JSON.stringify 的 replacer 参数 JSON.stringify(obj, (key, value) { if (value instanceof Date) { return { __type: Date, value: value.toISOString() } } return value })三种方案的取舍时间戳数值最小且比较运算方便但可读性差ISO 字符串可读性强、带时区信息自定义序列化可以携带类型标记便于反序列化时精确还原为Date对象代价是需要配套的解析逻辑。若使用 JacksonJava还可通过JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)注解在字段级固定日期格式避免前后端各自猜测。循环引用问题问题对象存在循环引用时序列化直接报错。const obj { name: test } obj.self obj JSON.stringify(obj) // TypeError: Converting circular structure to JSON解决方案// 方案一用 replacer 过滤循环引用 const seen new WeakSet() JSON.stringify(obj, (key, value) { if (typeof value object value ! null) { if (seen.has(value)) return seen.add(value) } return value }) // 方案二使用 flatted 库 import { parse, stringify } from flatted stringify(obj) // 自动处理循环引用理解JSON.stringify的第二个参数replacer是掌握这两个方案的关键replacer 会对每个键值对回调返回undefined即跳过该键因此用WeakSet记录已访问对象即可在第二次遇到同一对象时跳过从而打断环flatted库则通过特殊的索引引用格式完整保留循环结构代价是格式不再兼容标准 JSON 解析器。中文乱码问题问题中文序列化后出现乱码如å¼ ä¸。原因字符编码不一致UTF-8 与 GBK 混用BOM 标记干扰解析解决方案# Python确保使用 UTF-8 import json json.dumps(data, ensure_asciiFalse) # 不转义中文字符// Node.js显式设置响应头 res.setHeader(Content-Type, application/json; charsetutf-8)实践要点ensure_asciiFalse让 Python 输出原始中文字符而非\uXXXX转义序列便于日志与排障Node.js 侧务必在响应头声明charsetutf-8避免浏览器或下游按默认编码如 Windows-1252解析。若数据跨系统传输建议在 HTTP 层统一 UTF-8并在存储侧避免写入带 BOM 的文件因为 BOM 会被某些严格解析器当成字段名的一部分。实战电商系统的序列化方案设计场景分析场景格式选择理由App → 后端 APIJSON易调试前后端统一后端 → 后端 RPCProtobuf性能最佳节省带宽写入 Redis 缓存MessagePack比 JSON 小可序列化复杂对象日志记录JSON便于日志分析工具解析代码示例// API 响应JSON app.get(/api/products/:id, async (req, res) { const product await db.getProduct(req.params.id) res.json({ code: 0, data: product }) }) // 微服务通信Protobuf // product.proto syntax proto3; message Product { int32 id 1; string name 2; int32 price 3; } // 服务端 const proto require(./product.proto) const message proto.Product.create(product) const buffer proto.Product.encode(message).finish() // 客户端 const decoded proto.Product.decode(buffer) // Redis 缓存MessagePack const msgpack require(msgpack-lite) await redis.set( product:${id}, msgpack.encode(product) ) const cached msgpack.decode(await redis.get(product:${id}))这套分场景多格式策略的核心理念是在合适的边界使用合适的格式对外部客户暴露 JSON 保持可调试性与生态兼容在内部微服务之间用 Protobuf 压缩体积与延迟在 Redis 中混用 MessagePack 提升缓存吞吐日志统一 JSON 便于 Elasticsearch 等分析工具直接索引。这正是互联网后端中常见的混合序列化架构与 微服务演进、缓存设计 等主题相互呼应。用 AI 辅助序列化方案选型序列化选型涉及场景、性能、带宽、跨语言等多维约束AI 助手可以作为架构决策的参谋。下面是可直接复用的提示词模板与完整示例。Prompt 模板你是一名资深的系统架构师精通数据序列化技术。请帮我选择合适序列化方案。 ## 业务场景 [描述你的场景例如电商 App、游戏后端、微服务等] ## 技术要求 [列出约束条件例如 - 前后端分离Vue Node.js - 高性能要求QPS 10000 - 对流量敏感移动端需要省流量 - 需要跨语言Java Python Go] ## 数据特征 [描述数据特点例如 - 数据量大单次响应 1MB - 结构复杂多层嵌套 - 包含日期、二进制等特殊类型] ## 输出格式 请按以下格式输出 1. 推荐方案JSON/Protobuf/MessagePack/XML 2. 理由说明 3. 性能对比预估体积和速度 4. 代码示例实际示例输入 Prompt你是一名资深系统架构师。我们的电商 App 需要优化商品列表接口性能。 ## 业务场景 - 电商 App 的商品列表接口 - 每次返回 100 个商品 - 每个商品包含id、name、price、image、description 等 20 余个字段 - 当前使用 JSON响应约 200KB耗时约 800ms ## 技术要求 - 前端是 Vue.js - 后端是 Node.js Go 微服务 - 需要平衡性能与开发效率 ## 优化目标 - 响应时间降到 300ms 以内 - 数据包体积降低 30%AI 输出推荐方案混合方案 1. **API 层**继续使用 JSON对前端友好 2. **微服务通信**改用 Protobuf提升性能 3. **静态数据**开启 gzip 压缩 ### 理由说明 - JSON 对前端最友好无需额外解析 - 后端微服务使用 Protobuf 可降低 40% 数据量 - gzip 对文本压缩效果显著JSON 可压缩 70% ### 性能对比 | 方案 | 体积 | 耗时 | |------|------|------| | 现状JSON | 200 KB | 800 ms | | gzip | 60 KB | 350 ms | | Protobuf | 50 KB | 280 ms | ### 代码示例 [具体实现代码...]这个案例揭示了两个关键洞察其一压缩与序列化格式可以叠加使用——gzip 作用于文本格式JSON/XML收益明显而 Protobuf 这类二进制格式内部已高度紧凑压缩收益有限其二性能优化应优先改内部链路而非外部接口——对外 API 保持 JSON把 Protobuf 引入微服务内网用最小改造成本获得最大收益。术语表术语英文说明序列化Serialization对象 → 字节流反序列化Deserialization字节流 → 对象JSONJavaScript Object Notation最常用的文本格式XMLExtensible Markup Language标记语言曾经的主流标准ProtobufProtocol BuffersGoogle 开源的高效格式MessagePack-JSON 的二进制版本编码Encoding字符 → 字节解码Decoding字节 → 字符延伸阅读序列化是后端数据链路的翻译层它与仓库中的多个主题紧密相关建议按需深入HTTP 协议理解字节流如何在传输层封装API 设计JSON 响应结构、字段命名与版本化策略缓存设计序列化格式对缓存命中与吞吐的影响计算机基础之数据编码存储字符编码、字节序等底层知识【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 easy-vibe 序列化原理与实战：掌握 JSON、XML、Protobuf、MessagePack 数据翻译全链路
easy-vibe 序列化原理与实战掌握 JSON、XML、Protobuf、MessagePack 数据翻译全链路【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe序列化Serialization是把内存中的对象翻译成可传输格式、反序列化Deserialization再把传输格式还原成对象的过程是前后端通信、微服务 RPC、分布式缓存与持久化存储共同依赖的基础设施。本文以 easy-vibe 课程仓库docs/de-de/appendix/4-server-and-backend/serialization.md为骨架结合仓库中配套的交互式演示组件与本地化数据系统讲解序列化的必要性、四大主流格式的取舍、跨语言实现对照、性能差异、高频踩坑点与电商级实战方案读完后你将能够依据业务场景独立完成序列化技术选型并落地代码。为什么需要序列化三个必须解决的真实场景前端与后端交互时数据要经过多次变形才能从服务器抵达客户端。以下三个场景直接回答了为什么必须序列化。场景一前端拿到的数据变了样后端发送的是一个日期对象但前端收到的却是一个字符串// 后端发送 Date birth new Date(1990, 5, 15) // 前端接收 { birth: 1990-06-15T00:00:00Z } // 一个字符串前端想调用.getFullYear()却直接报错——因为收到的根本不是Date对象而是字符串。这正是跨语言、跨运行时数据表达不一致的典型后果JavaScript 的Date在 JSON 世界里没有原生对应物只能退化成字符串。场景二中文字符变成乱码// 期望的结果 { name: 张三 } // 实际收到的 { name: å¼ ä¸ }字符编码不一致例如发送端用 UTF-8、接收端按 GBK 解读或反之会把多字节字符拆成错误的字节序列产生不可读的乱码。场景三性能瓶颈// 一次返回 10000 条商品记录的响应 { products: [ { id: 1, name: ..., description: ..., ... }, // ... 其余 9999 条 ] } // 体积5.2 MB传输耗时3.5 秒JSON 文本格式的冗余大量{}、、逗号与字段名重复导致数据包过大严重拖累传输性能。一句话本质序列化就是翻译——把内存对象翻译成可传输格式接收方再把它翻译回来。上述三个场景分别是翻译后含义丢失、翻译时字符表不一致和翻译产物过于臃肿的问题。序列化与反序列化的概念与动机序列化Serialization将对象转换为可传输格式的过程即对象 → 字节流。反序列化Deserialization将传输格式还原为对象的过程即字节流 → 对象。包裹快递类比快递流程序列化环节说明打包物品序列化把物品装进箱子、贴上标签运输网络传输快递车把包裹运到目的地拆箱取物反序列化收件人打开箱子、取出物品类比的关键在于箱子和标签传输格式是标准化的所以无论寄件人发送进程和收件人接收进程使用什么语言、什么平台只要遵循同一套标准就能无损还原。为什么必须有序列化原因说明典型场景网络传输网络只能传输字节流API 调用、RPC 通信持久化存储磁盘只能保存字节对象存入文件或数据库跨语言不同语言的数据结构不同Java 对象 → Python 字典分布式缓存Redis/Memcached 存储字节缓存用户信息从这四类动机可以看出只要存在进程边界网络、磁盘、语言、中间件就必然存在序列化。这也是 easy-vibe 后端基础章节把它列为必学主题的原因——它位于 4-server-and-backend 系列文档 之中与 API 设计、缓存 等主题共同构成后端知识底座。主流序列化格式全景仓库为该主题配套了一个可交互演示组件 SerializationDemo.vue它用内存对象 → JSON 字符串 → 二进制三步动画直观展示序列化全流程并在底部给出格式对比评分表。该组件在 主题组件注册表 与 站点配置 中挂载对应的英文文案与数据定义在 server-backend/en.js。读者在本地运行npm run dev后即可在对应页面点击体验。JSON通用性最强优点可读性好便于调试所有语言都支持浏览器原生支持JSON.parse/JSON.stringify缺点体积大大量{}标记不支持丰富的数据类型Date、Map、Set 会被转成字符串应用场景公共 API、前后端通信、配置文件。XML曾经的主流标准?xml version1.0 encodingUTF-8? user id123/id name张三/name emailzhangsanexample.com/email age28/age /user优点结构清晰支持注释支持复杂嵌套有 Schema 校验XSD缺点体积大、解析慢标签冗余open/open成对出现应用场景配置文件Spring、MyBatis、SOAP 协议、复杂数据交换。Protobuf效率最高// user.proto syntax proto3; message User { int32 id 1; string name 2; string email 3; int32 age 4; }优点体积小比 JSON 小 30%–50%速度快解析速度是 JSON 的 5–10 倍向后兼容新增字段不影响旧版本缺点不可读二进制格式需要.proto定义文件不支持动态类型应用场景微服务内部通信、高性能场景游戏、实时通信、移动端省流量。补充原理Protobuf 之所以小且快关键在于.proto中每个字段的编号 1、 2…会被编码进二进制流作为字段标识因此字段名完全不出现在传输数据中传输字节只包含字段编号、类型标记wire type与值本身。仓库演示数据中给出了一个直观的字节级示例见 server-backend/en.js08 7b # field 1, varint 123 12 05 # field 2, length 5 41 6c 69 63 65 # UTF-8 Alice 1a 11 # field 3, length 17 61 6c 69 63 65 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 20 1c # field 4, varint 28整条User消息只需 38 字节这正是 Protobuf 高压缩比的结构性来源。MessagePack可读性与性能的平衡点// MessagePack 是 JSON 的二进制版本 // 同样数据MessagePack 比 JSON 大约小 30%优点比 JSON 更小、更快保持 JSON 的数据模型支持全部 JSON 类型缺点不可读效率不如 Protobuf应用场景需要性能但不想引入 Protobuf 的场景、Redis 缓存、WebSocket 消息。交互演示与格式对比SerializationDemo.vue 内置 JavaScript / Python / Java / Go 四种语言的演示左侧展示各语言的内存对象代码中间经序列化 → 二进制化两步箭头动画过渡右侧给出二进制十六进制片段与字节数。有意思的是Java 的二进制面板显示的是AC ED 00 05 73 72 ...约 150 字节这正是 Java 原生Serializable序列化的魔数头部AC ED与冗长的类元数据——直观说明语言自带序列化不一定比通用二进制格式高效。演示底部的对比评分表来自 server-backend/en.js从体积、速度、可读性、跨语言四个维度给出星级评价格式体积速度可读性跨语言JSON★★★☆☆★★★☆☆★★★★★★★★★★XML★★☆☆☆★★☆☆☆★★★★★★★★★★Protobuf★★★★★★★★★★★☆☆☆☆★★★★☆MessagePack★★★★☆★★★★☆★★☆☆☆★★★★★各语言序列化方案对照无论你使用哪种后端语言序列化都是日常开发的高频操作。下面是主流语言的常用库速查表语言JSON 库Protobuf 库XML 库JavaScriptJSON.stringify()protobuf.jsfast-xml-parserPythonjson.dumps()protobufxmltodictJavaJackson/Gsonprotobuf-javaJAXBGoencoding/jsonprotoencoding/xmlCnlohmann/jsonprotobuftinyxml2C#System.Text.JsonGoogle.ProtobufSystem.Xml选型建议前后端通信JSON便于调试微服务内部Protobuf性能最佳配置文件JSON 或 YAML对接遗留系统XML可能别无选择值得一提的是仓库演示数据还覆盖了 Go 的gob编码与 Java 原生序列化见 server-backend/en.js可以作为上表的补充视角Go 的gob是一种高效二进制编码但一般只用于 Go 语言内部进程间交换Java 原生序列化虽然零依赖却因携带完整类描述信息而体积偏大且存在安全风险现代 Java 服务更倾向 Jackson/Gson 搭配显式 DTO。性能对比体积与速度数据体积对比以用户对象为例格式体积相对 JSONJSON68 字节100%XML142 字节209%Protobuf38 字节56%MessagePack52 字节76%以上 JSON 68 字节、MessagePack 52 字节、Protobuf 38 字节的数据与演示组件中的jsonSize/binarySize字段完全一致见 server-backend/en.js可作为课程内部基准参考。XML 因成对标签的冗余开销达到 JSON 的两倍以上。速度对比序列化 1 万次格式耗时相对 JSONJSON45 ms100%XML120 ms267%Protobuf8 ms18%MessagePack28 ms62%性能测试结论Protobuf 最快适合高性能场景MessagePack 次之比 JSON 快约 40%JSON 最慢但对大多数场景已经足够需要说明的是这些数字是课程文档中用于横向比较的基准数据实际性能会受数据规模、字段结构、库实现与运行环境影响落地前建议基于自身真实数据做压测验证。常见问题与解决方案日期序列化问题问题Date 对象序列化后变成字符串。// 序列化之前 const date new Date(2024-01-01) // 序列化之后 JSON.stringify(date) // 2024-01-01T00:00:00.000Z解决方案// 方案一转成时间戳 { createdAt: date.getTime() } // 1704067200000 // 方案二转成 ISO 字符串 { createdAt: date.toISOString() } // 2024-01-01T00:00:00.000Z // 方案三自定义序列化利用 JSON.stringify 的 replacer 参数 JSON.stringify(obj, (key, value) { if (value instanceof Date) { return { __type: Date, value: value.toISOString() } } return value })三种方案的取舍时间戳数值最小且比较运算方便但可读性差ISO 字符串可读性强、带时区信息自定义序列化可以携带类型标记便于反序列化时精确还原为Date对象代价是需要配套的解析逻辑。若使用 JacksonJava还可通过JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)注解在字段级固定日期格式避免前后端各自猜测。循环引用问题问题对象存在循环引用时序列化直接报错。const obj { name: test } obj.self obj JSON.stringify(obj) // TypeError: Converting circular structure to JSON解决方案// 方案一用 replacer 过滤循环引用 const seen new WeakSet() JSON.stringify(obj, (key, value) { if (typeof value object value ! null) { if (seen.has(value)) return seen.add(value) } return value }) // 方案二使用 flatted 库 import { parse, stringify } from flatted stringify(obj) // 自动处理循环引用理解JSON.stringify的第二个参数replacer是掌握这两个方案的关键replacer 会对每个键值对回调返回undefined即跳过该键因此用WeakSet记录已访问对象即可在第二次遇到同一对象时跳过从而打断环flatted库则通过特殊的索引引用格式完整保留循环结构代价是格式不再兼容标准 JSON 解析器。中文乱码问题问题中文序列化后出现乱码如å¼ ä¸。原因字符编码不一致UTF-8 与 GBK 混用BOM 标记干扰解析解决方案# Python确保使用 UTF-8 import json json.dumps(data, ensure_asciiFalse) # 不转义中文字符// Node.js显式设置响应头 res.setHeader(Content-Type, application/json; charsetutf-8)实践要点ensure_asciiFalse让 Python 输出原始中文字符而非\uXXXX转义序列便于日志与排障Node.js 侧务必在响应头声明charsetutf-8避免浏览器或下游按默认编码如 Windows-1252解析。若数据跨系统传输建议在 HTTP 层统一 UTF-8并在存储侧避免写入带 BOM 的文件因为 BOM 会被某些严格解析器当成字段名的一部分。实战电商系统的序列化方案设计场景分析场景格式选择理由App → 后端 APIJSON易调试前后端统一后端 → 后端 RPCProtobuf性能最佳节省带宽写入 Redis 缓存MessagePack比 JSON 小可序列化复杂对象日志记录JSON便于日志分析工具解析代码示例// API 响应JSON app.get(/api/products/:id, async (req, res) { const product await db.getProduct(req.params.id) res.json({ code: 0, data: product }) }) // 微服务通信Protobuf // product.proto syntax proto3; message Product { int32 id 1; string name 2; int32 price 3; } // 服务端 const proto require(./product.proto) const message proto.Product.create(product) const buffer proto.Product.encode(message).finish() // 客户端 const decoded proto.Product.decode(buffer) // Redis 缓存MessagePack const msgpack require(msgpack-lite) await redis.set( product:${id}, msgpack.encode(product) ) const cached msgpack.decode(await redis.get(product:${id}))这套分场景多格式策略的核心理念是在合适的边界使用合适的格式对外部客户暴露 JSON 保持可调试性与生态兼容在内部微服务之间用 Protobuf 压缩体积与延迟在 Redis 中混用 MessagePack 提升缓存吞吐日志统一 JSON 便于 Elasticsearch 等分析工具直接索引。这正是互联网后端中常见的混合序列化架构与 微服务演进、缓存设计 等主题相互呼应。用 AI 辅助序列化方案选型序列化选型涉及场景、性能、带宽、跨语言等多维约束AI 助手可以作为架构决策的参谋。下面是可直接复用的提示词模板与完整示例。Prompt 模板你是一名资深的系统架构师精通数据序列化技术。请帮我选择合适序列化方案。 ## 业务场景 [描述你的场景例如电商 App、游戏后端、微服务等] ## 技术要求 [列出约束条件例如 - 前后端分离Vue Node.js - 高性能要求QPS 10000 - 对流量敏感移动端需要省流量 - 需要跨语言Java Python Go] ## 数据特征 [描述数据特点例如 - 数据量大单次响应 1MB - 结构复杂多层嵌套 - 包含日期、二进制等特殊类型] ## 输出格式 请按以下格式输出 1. 推荐方案JSON/Protobuf/MessagePack/XML 2. 理由说明 3. 性能对比预估体积和速度 4. 代码示例实际示例输入 Prompt你是一名资深系统架构师。我们的电商 App 需要优化商品列表接口性能。 ## 业务场景 - 电商 App 的商品列表接口 - 每次返回 100 个商品 - 每个商品包含id、name、price、image、description 等 20 余个字段 - 当前使用 JSON响应约 200KB耗时约 800ms ## 技术要求 - 前端是 Vue.js - 后端是 Node.js Go 微服务 - 需要平衡性能与开发效率 ## 优化目标 - 响应时间降到 300ms 以内 - 数据包体积降低 30%AI 输出推荐方案混合方案 1. **API 层**继续使用 JSON对前端友好 2. **微服务通信**改用 Protobuf提升性能 3. **静态数据**开启 gzip 压缩 ### 理由说明 - JSON 对前端最友好无需额外解析 - 后端微服务使用 Protobuf 可降低 40% 数据量 - gzip 对文本压缩效果显著JSON 可压缩 70% ### 性能对比 | 方案 | 体积 | 耗时 | |------|------|------| | 现状JSON | 200 KB | 800 ms | | gzip | 60 KB | 350 ms | | Protobuf | 50 KB | 280 ms | ### 代码示例 [具体实现代码...]这个案例揭示了两个关键洞察其一压缩与序列化格式可以叠加使用——gzip 作用于文本格式JSON/XML收益明显而 Protobuf 这类二进制格式内部已高度紧凑压缩收益有限其二性能优化应优先改内部链路而非外部接口——对外 API 保持 JSON把 Protobuf 引入微服务内网用最小改造成本获得最大收益。术语表术语英文说明序列化Serialization对象 → 字节流反序列化Deserialization字节流 → 对象JSONJavaScript Object Notation最常用的文本格式XMLExtensible Markup Language标记语言曾经的主流标准ProtobufProtocol BuffersGoogle 开源的高效格式MessagePack-JSON 的二进制版本编码Encoding字符 → 字节解码Decoding字节 → 字符延伸阅读序列化是后端数据链路的翻译层它与仓库中的多个主题紧密相关建议按需深入HTTP 协议理解字节流如何在传输层封装API 设计JSON 响应结构、字段命名与版本化策略缓存设计序列化格式对缓存命中与吞吐的影响计算机基础之数据编码存储字符编码、字节序等底层知识【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考