原始类型本身不参与一致性协议，其跨进程传输需显式序列化（如JSON、ArrayBuffer），而WebRTC仅提供低延迟字节传输，不内置任何分布式一致性机制。
原始类型在分布式计算中不涉及“序列化一致性协议”这个概念——它本身不是一种协议，也不属于 WebRTC 或通用分布式系统中定义的一致性保障机制。
原始类型本身不参与一致性协议
JavaScript 中的原始类型（如 number、string、boolean、null、undefined、symbol、bigint）是值语义、不可变、无状态的。它们在跨进程或跨网络传输前，必须被序列化为字节流（如 JSON、ArrayBuffer、MessagePack 等格式），而这个过程由开发者或框架显式控制，并不触发任何分布式一致性协议。
WebRTC 是点对点实时通信协议栈，核心关注媒体流（音视频）、数据通道（DataChannel）的低延迟传输，它不内置任何数据一致性协议。DataChannel 传输的是裸字节（ArrayBuffer 或 Blob），上层应用需自行约定编码方式和语义解释规则。
真正起作用的是应用层约定与传输保障
当两个 WebRTC 端交换原始类型值时，常见做法是：
- 用
JSON.stringify()序列化为字符串，再通过 DataChannel 发送；接收端用JSON.parse()还原 —— 这依赖 JSON 的确定性编码规则（如number总是转为十进制字符串，undefined会被忽略），但不提供跨节点状态同步保证； - 对性能敏感场景，用
TypedArray+ArrayBuffer手动布局结构（如把 3 个float32打包成 12 字节），靠二进制协议对齐字节序和字段偏移 —— 此时“一致性”仅指双方使用相同解析逻辑，而非分布式系统意义上的状态一致； - 若需多端共享并同步某个原始值（如计数器、开关状态），必须引入外部协调机制，例如结合 Signal Server + WebSocket 推送变更，或接入 CRDT 库（如
yjs）处理并发更新 —— 这些才是真正的分布式一致性方案。
别混淆序列化格式与一致性协议
序列化（如 JSON、Protocol Buffers）解决的是“如何把内存值变成可传输的字节”，而一致性协议（如 Paxos、ZAB、Raft）解决的是“多个副本如何就某个值的最终取值达成共识”。前者是静态编码规则，后者是动态容错协商过程。WebRTC 没有内置后者，也不需要 —— 它的设计目标是实时性与端到端直连，而非强一致状态协同。
所以，当你看到“原始类型在 WebRTC 中保持一致”，实际含义只是：发送方和接收方使用了兼容的序列化/反序列化逻辑，且网络未损坏数据。这不是协议保障的结果，而是开发约定与传输层校验（如 SCTP 的 CRC）共同作用的副产品。
