CRDT 与分布式数据结构

• 多主写入的冲突产生
• LWW（last-writer-wins）策略
• 冲突解决策略矩阵的边界

Cosmos DB 支持多主写入，多个区域可同时写同一数据，必然产生冲突。数据库提供可配置的冲突解决策略：1) LWW（Last-Writer-Wins，最后写入者胜）：用时间戳（SQL 的 _ts 或自定义属性）决定哪个写入胜出，时间戳最新的覆盖旧的。优点是简单、自动、无需客户端介入；缺点是依赖可信时钟，若时钟漂移或时间戳相同则可能错误覆盖，且丢失"冲突的合并信息"。2) Custom Procedure（自定义冲突解决存储过程）：在集合上注册一个自定义存储过程，冲突发生时由数据库在新写入的冲突副本上执行该过程，程序显式合并或丢弃。优点是灵活（可自定义合并语义）；缺点是逻辑复杂、需在冲突副本上执行、LWW 无法覆盖的场景仍需手工。3) last-writer-wins 矩阵（冲突解决策略矩阵）：Cosmos 按"数据模型（document 或 key-value）"与"冲突解决策略（LWW 或 custom）"组合成矩阵，说明不同组合下冲突如何被处理及边界。边界：LWW 的边界是"无法表达部分合并、受时钟影响、冲突信息丢失"；custom proc 的边界是"需保证过程幂等、执行在冲突副本上、跨副本一致收敛取决于过程实现"。建议：多数场景用 LWW 即可；需要合并语义（如计数器、集合、协同编辑）时可考虑自定义过程或改用 CRDT。

多主写入的冲突本质是"并发写的合并"。LWW 以"时间戳最新"为简单排序规则，但丢失了合并语义；custom proc 提供程序化合并但需保证幂等与收敛。边界理解的关键是：LWW 牺牲"合并正确性"换"简单性"，custom proc 用"复杂度"换"灵活性"，协同编辑等高冲突场景应选 CRDT。

• RGA 的序列结构
• 并发插入的排序规则（悬垂指针）
• 删除用墓碑保证收敛

RGA 是一种序列 CRDT，把文本/列表表示为"插入节点链表"，每个节点带唯一 ID（如 [副本ID, 序号]）。并发插入到同一位置：当两个副本同时在同一引用位置后插入时，RGA 定义"悬垂指针"规则——每个插入节点 ID 携带一个唯一标识，且 ID 带全局排序（如按副本 ID + 序号）。若两个节点插入到同一父节点之后，RGA 按 ID 的字典序（或某全局偏序）确定先后，使两个副本看到相同的相对顺序，从而收敛。为什么用插入后悬垂指针排序：因为不依赖插入时的物理位置（两个副本在同一位置插入的顺序不同），而是用"每个节点的唯一 ID 的相对序"来确定顺序，这样无论哪个副本先看到哪个插入，最终顺序一致。删除用墓碑：序列删除不能物理移除节点，否则在其他副本上该节点可能仍被引用（别的节点的父指针指向它），且删除需要传播——若直接删，其他副本无法知道自己也删除了它。因此删除只做"墓碑"标记（标记该节点已删除但保留其在结构中的位置），保证所有副本对"哪些节点已删除"达成一致，从而收敛。墓碑最终可被 GC 清理（当所有副本都看到删除）。

RGA 的核心是"用节点唯一 ID 的全局序 + 悬垂指针"解决并发插入顺序，用"墓碑标记"解决并发删除。这样所有操作都是"映射到全序的单调更新"，满足收敛性要求。墓碑保留结构但占用空间，是序列 CRDT 正确性的代价。

• OT 的变换（transform）与 CRDT 的合并
• 合并策略的差异
• 实现复杂度与容错

OT（Operational Transformation）：以"操作变换"为核心——每个操作（插入/删除）在与并发操作合并时，通过 transform 函数把操作变换到对方上下文后再应用，使最终文档一致。OT 需要中心服务器协调（通常是 Google Docs 的架构），操作按顺序 transform，先后顺序依赖服务器；复杂度高，transform 函数需处理各种边界情况（如并发插入同一位置、删除被插入内容），且随操作类型增多而爆炸。CRDT：以"数据结构本身的代数性质"为核心——每个操作都是幂等、交换、结合的合并，任意副本收到任意顺序的操作都能收敛到同一状态，无需中心服务器、无需 transform。对比：1) 合并策略：OT 用 transform 操作适配上下文，CRDT 用可交换的合并运算；2) 架构：OT 依赖中心服务器保持操作顺序，CRDT 可去中心化、任意 order 合并；3) 复杂度：OT 的 transform 逻辑复杂、易出错、难扩展，CRDT 的合并简单但数据结构和元数据（ID、墓碑）复杂；4) 容错：OT 对乱序/丢包敏感，CRDT 天然容忍乱序与重放；5) 性能：OT 操作小、元数据少，CRDT 需携带 ID/墓碑、状态可能膨胀。趋势：Figma、Yjs 等用 CRDT，Google Docs 用 OT，CRDT 因去中心化与健壮性逐渐流行。

OT 与 CRDT 都能实现协作编辑，但思路相反：OT 在"操作"层面做变换适配上下文，依赖中心排序；CRDT 在"结构"层面保证合并可交换，去中心化。OT 的 transform 复杂度随操作与约束增长，CRDT 的复杂度在数据结构与元数据上。选型看是否有中心服务器、是否容忍乱序、状态膨胀的接受度。

• OR-Set 的每个元素带唯一标签
• 添加/删除的语义
• 墓碑机制与收敛

OR-Set（Observed-Remove Set）中，每个元素不只存值，还带一个唯一标签（tag/UID），集合实际存的是"（值, 标签）"对。添加：为元素生成一个新标签，把 (值, 标签) 加入集合。删除：不是删除"值"，而是删除该值对应的所有标签（即删除 (值, 标签) 对）。并发语义：添加总是生成新标签，删除只移除已知标签；因为"删除"针对的是"已观察到的标签"，而"并发添加"产生的新标签不在删除范围内，所以并发添加不会被删除误伤——这就是"observed-remove（观察再删除）"的含义。墓碑机制：当删除发生时，为了确保删除能被所有副本感知并收敛，通常保留一个"墓碑"（记录已删除的标签），而不是立即物理清除。这样：若一个副本先添加、另一个副本先删除，合并时通过墓碑知道"该标签已被删除"，从而一致地移除；若删除早于添加到达，墓碑保证新来的添加标签不会复活已删除的值。收敛：所有副本通过"标签 + 墓碑"对每个值达成一致（是否在集合中），最终收敛。墓碑可随 GC 清理（当所有副本都确认删除）。

OR-Set 解决了"并发添加与删除"的经典问题：删除不能无条件删除元素，否则会误删并发的添加。用"标签 + 观察删除"把删除限定到具体标签，用墓碑保证删除的传播与收敛。这是 CRDT 集合的实现基础。

• Yjs 的 CRDT 核心（Y.Map、Y.Array、Y.Text）
• 块级同步与二进制编码
• 离线编辑、重连与冲突恢复

Yjs 是一个基于 CRDT 的协同编辑库，核心是 Y.Map、Y.Array、Y.Text 等类型，数据以 CRDT 结构存储，支持任意顺序合并。连接与同步：通过 provider（如 y-websocket、y-indexeddb）与服务器或 peer 连接，用二进制编码的更新（update）增量同步；每个文档有版本向量（clock），同步时只传输缺失的增量，避免全量传输。离线编辑：本地用 IndexedDB provider 持久化更新，离线时 CRDT 照常打（本地合并），无需中心服务器。重新连接：断线重连后，双方交换版本向量，只同步缺失的增量块，CRDT 的交换性保证无论以何种顺序合并都收敛到一致状态。冲突恢复：并发操作（如 Y.Text 在同一位置插入、Y.Map 的并发 set）由 CRDT 的合并规则自动收敛——Y.Text 用类似 YATA/RGA 的算法确定并发插入顺序，Y.Map 用 last-write-wins 或按客户端 ID 排序；无需人工解决，最终一致。白板/表格/设计工具：白板用 Y.Map 存图元位置、Y.Array 存图层列表；表格用 Y.Map 存单元格；设计工具用 Y.Map+嵌套结构表示对象树。所有操作都是 CRDT 更新，天然支持离线与重连。

Yjs 的能力来自"CRDT 合并 + 版本向量增量同步 + 本地持久化"三者的结合：CRDT 保证冲突自动收敛，版本向量保证只传缺失增量、带宽高效，IndexedDB 保证离线可编辑。重连后只需同步缺失块，无需全量重放，冲突由 CRDT 自动解决。

• 文档大小与操作/元数据的关系
• 压缩率与编码
• 压缩时机与 GC 对内存的影响

文档大小：Yjs/Automerge 文档由 CRDT 结构（操作 + 元数据）组成，每个操作携带客户端 ID、时钟、内容等元数据，大小与"操作数 × 每操作元数据"成正比。估算时可参考：文本插入每字符约几字节到几十字节（含 ID/时钟/长度编码），随编辑次数增长（额外的删除/移位操作也计入）。压缩率：二进制编码（Yjs 的 update 用 varint + 结构编码）比 JSON 紧凑，压缩率受操作重复度影响；当操作含大量重复 ID/时钟时可高效压缩。压缩时机：定期或达到阈值时对文档做压缩/合并（把多个操作合并为更紧凑的形式，去除冗余历史），减少传输与存储量。GC 策略：CRDT 的 tombstone（删除标记）会无限增长，占用内存。GC（如 Yjs 的基础 GC 或自定义）在"所有副本都确认删除后"清理墓碑，释放内存；但清理需谨慎——若某副本尚未同步确认，过早清理会导致该副本复活已删除内容或丢失数据。对内存的影响：频繁编辑 + 大量墓碑会显著增大内存；定期压缩 + 全量确认后的 GC 可控制内存增长，但 GC 时机错误会破坏收敛。权衡：压缩与 GC 降低内存/带宽，但增加复杂度与 CPU 开销，需在"状态大小"与"安全"间平衡。

估算大小要基于"操作数 × 元数据"，压缩要理解二进制编码的紧凑性，GC 要理解"墓碑安全回收"的前提（所有副本确认）。压缩时机与 GC 直接影响内存：越频繁越小但开销越大，且 GC 必须保证所有副本已同步该删除，否则会破坏收敛性。

• 非交换操作导致不收敛
• 冲突解决策略的错误
• 正确性验证

CRDT 的常见误区包括：1) 非交换操作：CRDT 要求所有操作（或合并）是可交换、结合、幂等的，若实现中用"非交换"的操作（如依赖顺序的覆盖、依赖上下文的状态），不同副本按不同顺序合并会得到不同结果，导致不收敛。必须保证操作之间交换不影响最终状态。2) 冲突解决策略错误：如 LWW 用物理时钟，时钟漂移会导致错误覆盖；或把"删除"实现为"移除元素"而非"墓碑"，导致并发添加被误删复活；或冲突解决偏向某副本导致其他副本的更新被丢弃。3) 忽略幂等性：操作重复投递（网络重放）必须幂等，否则重复应用导致状态错误。4) 依赖中心或全局顺序：CRDT 应无顺序依赖，若实现假设操作有全局顺序（如依赖服务器 chrono），去中心化失效。5) 元数据/墓碑管理不当：墓碑无限增长、或 GC 过早导致删除复活。对策：每个操作都验证"交换、结合、幂等"，用模拟时钟与随机重排测试收敛性，对所有副本合并结果做一致性断言。

CRDT 的正确性根基是"代数性质"（交换/结合/幂等），误区多源于违背这些性质或错误处理冲突语义。非交换操作是头号杀手，因为并发场景下副本合并顺序不同。解决之道是设计算子时验证代数性质，并用随机重排/重复的模糊测试验证收敛。

• 各 CRDT 的数据结构与语义
• 单调性（G vs PN）
• 集合的墓碑与观察删除

1. G-Counter（增长计数器）：每副本一个单调递增计数，整体取各副本计数之和，只增不减（语义：只加计数器）。合并取逐分量 max。2) PN-Counter（正负计数器）：由两个 G-Counter 组成（G 增、P 减），最终值 = 增长计数 - 减少计数，支持增减。3) G-Set（增长集合）：只增集合，元素只加不删，合并取并集。4) 2P-Set（two-phase set）：由 G-Set（添加）+ G-Set（移除/墓碑）组成，先添加、后移除；元素一旦从删除集合移除则不复存在（不可复活），合并取两集合并集。5) OR-Set（观察移除集合）：每个元素带标签，删除只移除已观察到的标签，并发添加不受删除影响（可复活），合并按标签判重。6) LWW-Register（最后写入者胜寄存器）：存储 (值, 时间戳)，合并取时间戳较大的值，冲突按时间戳（或逻辑时钟）定胜者。冲突解决语义：G/PN 是计数合并（求和/逐分量 max），G-Set/2P-Set 是集合合并（并集/墓碑），OR-Set 是标签级观察删除，LWW-Register 是时间戳覆盖。不同 CRDT 对应不同业务语义（单调计数、不可复活集合、可复活集合、寄存器覆盖）。

这些 CRDT 是"合并语义"的枚举：按"状态类型"（计数/集合/寄存器）与"合并规则"（求和/max/并集/墓碑/时间戳）组合。G 系列单调、PN 支持增减、2P-Set 不可复活、OR-Set 可复活、LWW 覆盖。理解它们的关键是"合并后各副本一致"与"语义符合业务需求"两点。

• CvRDT：状态合并（join-semilattice）
• CmRDT：操作合并（可交换操作）
• 区别与适用场景

CRDT 分为两大类：CvRDT（基于状态收敛，即 state-based CRDT）：副本之间通过合并整个状态来同步，采用 join-semilattice（偏序合并）结构，合并是幂等、交换、结合的（如取并集、逐分量 max）。副本交换完整状态，合并后收敛。CmRDT（基于操作收敛，即 op-based CRDT）：副本之间通过传播操作来同步，要求操作互为可交换（convergent），且依赖可靠传递（至少一次、先序保证）。副本应用操作后收敛。区别：1) 同步粒度：CvRDT 传状态（可能大），CmRDT 传操作（小但需因果/可靠）；2) 收敛机制：CvRDT 靠合并（join），CmRDT 靠交换操作；3) 容错：CvRDT 对丢包/乱序健壮（真实状态合并即可），CmRDT 对乱序敏感（需可靠有序分发）；4) 带宽：CvRDT 全状态传输带宽高，CmRDT 操作传输带宽低但需可靠通道。适用场景：CvRDT 适合"状态小、可定期全量同步、容忍乱序"的场景（如去中心化、弱网络）；CmRDT 适合"操作小、有可靠传输通道（如中心服务器/消息队列）"的场景（如协同编辑的增量同步）。实际中常结合（如 Delta-CRDT 用增量状态）。

分类的本质是"同步什么"：CvRDT 同步状态（靠 join 收敛），CmRDT 同步操作（靠交换收敛）。CvRDT 健壮但带宽大，CmRDT 高效但需可靠通道。理解二者区别有助于选型：弱网/无服务器选 CvRDT，中心化高带宽选 CmRDT。

• 每个结构的单调/可交换合并
• 无协调的收敛原理
• 幂等、交换、结合

这些结构的设计都遵循"合并可交换且幂等"原则，从而无需协调即可收敛。G-Counter：每副本一个只增计数，合并取逐分量 max，因为 max 是可交换、幂等、结合的，任意副本按任意顺序合并都得到相同结果（每分量取最大值）。PN-Counter：由两个 G-Counter（增、减）组成，合并并得到最终值，同样满足交换性。G-Set：合取并集，并集可交换、幂等、结合，最终一致。OR-Set：每个元素带标签，删除移除已观察标签，合并按标签取并集，标签的唯一性保证并发添加/删除不冲突，交换后一致。为什么无需协调：幂等性保证重复操作不改变结果；交换性保证任意顺序合并结果一致；结合性保证分批合并与整体合并一致。这三点（幂等、交换、结合）使每个副本无论收到什么顺序的状态/操作，都能收敛到同一最终状态，因而不需要中心协调或全局顺序。代价：需要额外的元数据（每副本计数、标签、墓碑），且每个操作只能是单调的或在结构上可交换的。

这些 CRDT 的收敛性来自"合并运算满足幂等、交换、结合"这一代数性质。只要合并满足这些性质，任意副本任意顺序合并状态都收敛到同一结果，从而天然实现最终一致、无需协调。这是 CRDT 的核心数学基础。

• LWW 依赖时间戳定胜者
• 物理时钟漂移问题
• 逻辑时钟与混合时钟的取舍

LWW-Register 用时间戳决定胜者，冲突解决完全依赖时钟，因此时钟依赖问题是核心：1) 物理时钟（wall clock）：简单直观，但存在时钟漂移与实际时间不可靠——不同机器时钟不同步，可能导致"后写"被"先写"覆盖（时间戳更小），或时钟回拨导致乱序。2) 逻辑时钟（Lamport 时钟）：用单调递增的计数器 + 副本 ID 保证全序，无漂移问题，能保证因果序，但与实际时间无关，无法反映"真实先后"，且长时间运行的节点计数器可能很大。3) 混合时钟（HLC，Hybrid Logical Clock）：结合物理时间与逻辑计数器——取"物理时间与逻辑时钟最大值"作为 HLC 时间，既接近墙上时间又保持因果序，缓解漂移并保留单调性。取舍：物理时钟简单但不可靠（漂移）；逻辑时钟可靠无漂移但丢真实时间；混合时钟兼顾二者（接近真实 + 保持因果 + 抗漂移），是分布式冲突解决的主流时钟。结论：LWW 用物理时钟易因漂移出错，用逻辑时钟保证因果但无真实时间，用 HLC 是折中；此外 LWW 本身只解决"覆盖类"冲突，对合并类（集合、文本）不适用。

LWW 的准确性与时钟质量直接相关。物理时钟的漂移是 LWW 的头号风险，逻辑时钟牺牲真实时间换可靠性，HLC 用"物理+逻辑"组合兼顾二者。工程上分布式系统多用 HLC 或带单调性的混合时钟做 LWW。注意 LWW 只适合"覆盖语义"，不适合合并类冲突。

• join-semilattice 定义
• 单调合并与幂等/交换/结合
• 收敛性证明思路

CRDT 收敛性的数学基础是join-semilattice（半格）：一个偏序集，其中任意两个元素都有唯一的最小上界（join，lub）。状态型 CRDT 把每个副本状态建模为半格上的元素，合并（merge）就是求 join。由于 join 运算满足幂等（join x x = x）、交换（join x y = join y x）、结合（join (join x y) z = join x (join y z)），且是单调的（x ⊑ join x y），因此任意副本无论按什么顺序合并收到的状态，最终都收敛到所有状态的 join（最小上界）。为什么保证最终一致：只要每个副本最终收到所有其他副本的状态（或足够多的状态），通过 join 合并，所有副本都收敛到整个状态集合的最小上界，即同一最终状态。单调性保证状态只前进不后退，join 保证合并结果唯一，从而无协调、无冲突排序即可收敛。证明思路：构造偏序（如集合包含、自然数序），证明合并是 join（满足幂等/交换/结合），再证明"所有副本经足够同步后状态均等于全局 join"，即完成收敛性证明。

join-semilattice 是 CRDT 收敛的"代数保证"：join 的幂等、交换、结合 + 单调性，使任意乱序合并都收敛到同一最小上界。这一性质是状态型 CRDT（CvRDT）可证明收敛的数学根因，也是"无协调最终一致"的理论基础。

• 序列 CRDT（YATA/RGA/富文本）
• 并发插入的排序
• 并发删除的墓碑

协同编辑的核心是序列 CRDT（处理文本/列表的插入与删除）。Yjs 和 Automerge 都实现了序列 CRDT。并发插入：两个副本在同一位置插入不同字符串时，需要确定一个统一的相对顺序。Yjs 用 YATA（YATA 算法）：每个插入项带唯一 ID（客户端 ID + 时钟），插入时指定"前驱/后继"关系，通过 ID 的偏序（如按客户端 ID + 时钟）确定并发插入的相对顺序，使所有副本看到相同顺序。Automerge 用 RGA：每个插入节点带唯一 ID，插入在同一位置时按 ID 全局序排序。并发删除：删除通过"墓碑"标记（tombstone），不物理移除节点，保留其结构位置；合并时所有副本都看到该节点被标记删除，从而一致地"隐藏"它。并发插入+删除：若某副本在别人删除的位置插入，删除只针对已知节点，新插入节点不受影响，按标签/ID 重新排序收敛。结果：Yjs/Automerge 通过"唯一 ID + 偏序排序 + 墓碑"处理并发插入与删除，保证多副本在线/离线任意顺序合并后文档一致，且支持富文本（Y.Text 的 formatting 用额外的 CRDT 属性）。

序列 CRDT 的核心是"用唯一 ID 定义插入的全局偏序 + 用墓碑处理删除"。Yjs 的 YATA 与 Automerge 的 RGA 是两种主流序列算法，都保证并发插入顺序一致、删除收敛。它们让协同编辑无需中心服务器即可同步。

• 元数据（标签、ID、墓碑）随操作增长
• tombstone 无限增长的原因
• GC 策略设计

CRDT 的每个操作都携带元数据（唯一 ID、时钟、标签、墓碑等）。OR-Set 的 tombstone 无限增长：删除时，元素并不物理移除，而是记录"已删除的标签"（墓碑）。为保持收敛，墓碑必须保留到"所有副本都确认删除"为止。但副本可能离线、延迟或永不回收，若无法确认所有副本都同步了删除，墓碑就不能清理，导致墓碑随删除次数无限增长，内存/存储持续膨胀。GC 策略设计：1) 全量确认（因果确认）：当所有副本都确认收到删除操作（如通过某种因果稳定/版本向量判定）后，才可清理墓碑——这是最安全的 GC；2) 定期压缩/快照：合并成 compact 状态，移除已确认的墓碑；3) 基于"稳定状态"的 GC：当某些操作已稳定（所有副本已应用）时回收；4) 结合 Delta 同步：用增量状态传播，减少全状态携带墓碑。权衡：GC 越激进（提前清理）内存越省但可能破坏收敛（若副本未同步会复活已删除元素）；GC 越保守（延迟清理）收敛越安全但内存膨胀。设计原则：GC 必须保证"被清理的 tombstone 已对所有副本可见 / 已确认"，否则会破坏 CRDT 的收敛性。

tombstone 无限增长源于"删除需要全局确认才能安全回收"。GC 的本质是"确认安全后再清理"，用版本向量/因果稳定判断哪些墓碑已被所有副本确认。激进 GC 省内存但风险高，保守 GC 安全但膨胀，需在两者间平衡，且多数实现用"全量确认 + 定期 compact"。

• OT 的中心化与 CRDT 的去中心化
• Google Docs 选 OT 的原因
• Figma 选 CRDT 的原因

OT：通过 transform 变换操作适配上下文，依赖中心服务器协调操作顺序，操作传输小、延迟低，但实现对 transform 的复杂依赖、容错性差（乱序/丢包）。CRDT：通过可交换合并收敛，去中心化、无需服务器排序、容忍乱序/重放，但元数据（ID、墓碑）占用大、状态可能膨胀。Google Docs 用 OT：Google 的架构本身是中心化的（服务器协调），且有严格的在线同步与低延迟要求；OT 在中心服务器下操作小、带宽低、延迟低，且 Google 团队对 OT 的 transform 有深厚积累，能处理复杂场景。Figma 用 CRDT：Figma 是多用户实时协作 + 需要离线/弱网复苏与去中心化的架构，且希望避免中心变换的复杂度；CRDT 的自动合并让不同客户端（含离线）任意顺序合并都收敛，无需中心排序，容错性强，且 Figma 的协作模型（对象级更新）适合 CRDT 的合并语义。取舍要点：有中心服务器、追求低带宽低延迟、能搞定 transform 用 OT；要去中心化、容忍离线/乱序、避免 transform 复杂度用 CRDT。CRDT 逐渐成为新应用的默认选择。

两者能达成同一目标（协同编辑），但架构偏好不同：OT 契合中心化 + 低延迟 + 小型操作，CRDT 契合去中心化 + 离线 + 健壮合并。Google Docs 的服务器中心架构 + 积累使其选 OT，Figma 的实时多端 + 离线需求使其选 CRDT。选型看架构与容错需求。

• state-based 合并状态
• op-based 合并操作
• 同步与带宽差异

state-based（基于状态，CvRDT）：副本之间同步的是整个状态，合并用 join（如取并集、逐分量 max）。接收方把收到的状态与本地状态 join，得到更"大"的状态。合并语义是"状态单调合并"，无需关心操作历史，任意状态合并都收敛。带宽高（全状态传输），但对乱序/丢包健壮（合并真实状态即可）。op-based（基于操作，CmRDT）：副本之间同步的是操作，接收方把收到的操作应用到本地状态。合并语义是"操作可交换且幂等"，要求操作在应用后不受顺序影响（互为交换）。带宽低（只传操作），但依赖可靠传递（至少一次、先序），对乱序/丢包敏感。差异：1) 同步内容：状态 vs 操作；2) 合并语义：join 状态 vs 应用操作；3) 带宽：全状态 vs 增量操作；4) 容错：状态型对乱序健壮，操作型需可靠通道；5) 实现：状态型简单（合并即可），操作型需保证操作可交换且可靠传输。联系：操作型可看作状态型在"操作可交换"条件下的特化，Delta-CRDT 是两者的折中（传增量状态）。

两种类型的合并语义差异在于"同步什么"：状态型合并状态（join），操作型合并操作（应用）。状态型健壮但带宽大，操作型高效但需可靠通道。理解差异有助于按网络条件与同步频率选型。

• G-Counter 的单调计数
• PN-Counter 的增减
• 合并规则

G-Counter（增长计数器）：只能单调递增，实现为"每副本一个计数"的向量。设有 n 个副本，每个副本 i 维护自己的计数 c[i]，本地增加时 c[i]++；整体值 = 所有 c[i] 之和。合并：两个副本合并时，逐分量取 max（c[i] = max(c[i], c'[i])），因为每副本计数只增不减，取 max 保留两者各自的最大增量。合并满足幂等、交换、结合，故收敛。PN-Counter（正负计数器）：支持增减，实现为两个 G-Counter：一个 inc（只增）、一个 dec（只减）。增加时 inc 加 1，减少时 dec 加 1；最终值 = inc 总和 - dec 总和。合并：inc 取逐分量 max，dec 取逐分量 max。这样增减都以单调计数器表达，合并仍收敛。实现要点：G-Counter 用"每副本向量 + 分量 max"表达单调；PN-Counter 用"两个 G-Counter（增/减）"表达有正有负；合并都靠逐分量 max。

单调性（G-Counter 让每分量只增不减）是收敛的关键，PN-Counter 用"增与减分离成两个单调计数器"来支持增减。逐分量 max 是幂等、交换、结合的合并，数学上保证收敛。这是计数型 CRDT 的标准实现。

• HLC 的物理部分 + 逻辑部分
• 因果序保持
• 与 Lamport 时钟的差异

HLC（Hybrid Logical Clock）：每个事件携带一个 (pt, l) 表示，其中 pt 是"逻辑部分"（接近物理时间，取物理时钟与检测到的最大逻辑时间的较大者），l 是"逻辑计数器"（在同一 pt 内递增）。当发送/接收事件时：pt = max(本地物理时间, 收到的最大 pt)，若 pt 前进则 l = 0，否则 l++。这样 HLC 时间既接近墙上时间（pt 跟随物理时间），又保持因果序（若事件 A 因果先于 B，则 HLC(A) < HLC(B)），且单调不后退。与 Lamport 时钟的差异：Lamport 只有逻辑计数器，完全脱离物理时间，无法反映真实时间，只能保证因果序（且会随事件快速增长）；HLC 在逻辑计数器基础上叠加物理时间，使时间戳接近真实时间且保持因果序、单调、抗时钟漂移。应用：HLC 常用于分布式数据库与 LWW 时间戳（如 CockroachDB、Spanner 的 TrueTime 改善、常见分布式系统），用接近真实的时间戳做冲突解决且保持因果。差异总结：Lamport 无物理时间、仅因果；HLC 有物理时间 + 逻辑计数器，兼顾真实时间与因果序。

HLC 是"物理时钟 + 逻辑计数器"的融合：物理部分贴近真实时间，逻辑部分保证在同一物理时间内的因果序与单调。相比 Lamport（纯逻辑），HLC 更实用（时间戳接近真实、可做 LWW），相比物理时钟（纯墙钟），HLC 抗漂移且保因果。这是分布式时间戳的主流工具。

• 离线优先应用的需求
• CRDT 的去中心化合并
• 断网编辑后自动合并

**离线优先（Local-First）**应用的核心需求是"用户离线也能编辑、数据存在本地、联网后自动合并"，传统中心化/强一致方案无法满足（离线时无法同步或冲突需人工处理）。CRDT 的价值：1) 去中心化：无需中心服务器，每个设备本地保存完整数据，离线可编辑；2) 自动合并：CRDT 的合并运算是幂等、交换、结合的，联网后各设备把本地状态/操作合并，自动收敛到一致状态，无需人工冲突解决；3) 容错：对乱序、丢包、重复投递健壮；4) 支持多端：手机、Web、桌面离线各自编辑，重连后合并。边缘计算：边缘节点（本地服务器）与云端都可离线处理，CRDT 让边缘与云端最终一致，无需强一致协调，降低网络依赖。如何实现断网编辑后自动合并：每个设备本地持久化 CRDT 状态（如 IndexedDB/SQLite），编辑生成 CRDT 操作并本地应用；联网后交换版本向量/增量，用 CRDT 合并（join）本地与远端状态，因合并可交换，所有设备收敛到同一状态。案例：Local-First 的工具（如笔记、数据库、协同编辑）用 Yjs、Automerge、CRDT 数据库（如 Replicache、ElectricSQL）实现离线编辑 + 自动合并。

CRDT 让"离线编辑 + 自动合并"成为可能，因为它消除了"需要服务器排序/协调"的依赖。每设备本地 CRDT 状态，联网后靠可交换合并自动收敛，天然契合离线优先与边缘计算。这是 Local-First 应用的核心技术。

• state-based CRDT 的全状态传输问题
• Delta-CRDT 的增量（delta）状态
• 增量合并与带宽优化

**state-based（CvRDT）**每个副本周期同步整个状态，带宽随状态大小增长，不适合大文档。Delta-CRDT的改进是：只传输"自上次同步以来的增量状态（delta）"，而非完整状态。原理：把状态型 CRDT 的合并分解为"应用 delta 到本地状态"——delta 是一个"较小状态"（只包含变更部分），接收方把 delta join 到本地即可。由于 CRDT 合并是可交换的，delta 可以脱离完整状态独立传播，多个 delta 可合并到同一状态。实现：每个副本维护一个"delta 状态"（只含本副本的变更），同步时只发送 delta；接收方合并 delta 到本地状态，并回传自己的 delta。带宽收益：只传变更增量，避免全状态传输，带宽大幅降低（尤其对大文档、低频改变的场景）。代价：delta 的合并仍需保证可交换、幂等，且若接收方错过某些 delta 需用完整状态或重放补齐；解码与合并逻辑更复杂。意义：Delta-CRDT 结合了 state-based 的健壮性与 op-based 的带宽效率，是 Yjs/Automerge 等实际系统实现增量同步的基础（Yjs 的 update 本质是 delta 状态）。

Delta-CRDT 把"全状态同步"优化为"状态增量同步"，用可交换的 delta 合并降低带宽，同时保留 state-based 对乱序的健壮性。它解决了 state-based CRDT 带宽大的问题，是实际协同系统的关键优化。

• Redis/云数据库的 CRDT 应用
• LWW vs 计数器的冲突语义
• 场景选择

CRDT 在工程数据库中有广泛应用。Redis：Redis Enterprise 与 Redis 的某些模块提供 CRDT 支持（如 Active-Active Redis 的 CRDT 类型），用于多数据中心/多主复制的冲突解决，如计数器、集合、字符串最后写入者胜等。云数据库：DynamoDB、Cosmos DB、Cassandra 等多主/多区域数据库内置 CRDT 或冲突解决——Cassandra 的计数器（counter）本质是 CRDT（G-counter/PN-counter），键值用 LWW；Cosmos DB 提供 LWW 与自定义合并；Amazon 的 CRDT 数据存储（如 AWS 的一些内部服务）用组合 CRDT。冲突解决选择（LWW vs 计数器）：**LWW（Register）**适合"覆盖语义"的数据（如用户资料、配置、单值字段），用时间戳/时钟定胜者，简单但丢失合并信息；**计数器（Counter）**适合"累加语义"的数据（如点赞数、库存、访问量），用单调计数合并，避免 LWW 覆盖导致计数丢失。选型原则：值可覆盖、语义是"单一值"用 LWW；值需累加、语义是"总数"用计数器（G/PN-Counter）；集合/协同结构用 OR-Set/序列 CRDT。工程注意：LWW 依赖时钟需防漂移，计数器需防丢更新（用单调计数而非覆盖）。

CRDT 在数据库中的价值是"多主/多区域无协调地解决写冲突"。选型看"语义"：覆盖类用 LWW，累加类用计数器，集合/文本用对应 CRDT。计数器能避免 LWW 覆盖导致的值丢失，是它相对 LWW 的优势。

• Automerge 的 CRDT 持久层
• 版本化存储
• 查询 DSL 与分布式集成

Automerge 是一个成熟的 CRDT 库，近年进展包括：1) CRDT 持久层：Automerge 提供高效持久化——以二进制格式（automerge binary）存储文档，支持增量更新与快照，用存储格式（如 automerge 的 save()/load()）持久化到本地，避免全量重放历史；2) 版本化存储：文档本身就是版本化结构（每次变更产生新版本），支持按版本查看历史、分支合并、diff 与回滚，类似 Git 的模型；3) 分布式/数据库集成：Automerge 与数据库（如 Postgres、SQLite、边缘数据库）集成作为持久层，或作为"无冲突复制"的存储引擎；Yjs 与 Automerge 常被用于协同编辑后端；4) 查询 DSL：Automerge 提供查询/索引能力（如对文档属性做索引、查询 API），支持对 CRDT 文档做高效查询而非全量遍历；5) 性能优化：Rust 核心（automerge-rs）重写，提升内存与速度，支持更大文档与增量同步（delta）。方向：把 CRDT 作为通用"可复制、可版本化、可查询"的数据层，服务于离线优先应用、协同编辑、分布式数据库。

Automerge 的进展体现了"CRDT 从算法走向基础设施"：高效的二进制持久化、版本化存储、查询能力、与数据库集成，让 CRDT 成为可用的数据层。Rust 重写提升性能，使其能支撑更大规模与更复杂应用。

• 最终一致 vs CRDT 收敛
• 向量时钟 vs CRDT 合并
• 边界与适用

最终一致（Eventual Consistency）：指系统在停止更新后，所有副本最终收敛到同一状态，但不保证收敛语义——可能依赖人工/服务器冲突解决，甚至可能不一致（如 LWW 覆盖）。CRDT：是一种保证收敛的数据结构，其合并运算是幂等、交换、结合的，数学上保证任何副本任意顺序合并后收敛到同一状态，无需人工干预。差异：最终一致是"性质"（可能收敛），CRDT 是"实现"（必然收敛）。向量时钟（Vector Clock）：是一种因果序追踪工具，用"每副本计数向量"记录因果依赖，用来判断"两个事件是否因果相关"和检测冲突，但它不解决冲突——只告诉你"有冲突"，具体如何合并（LWW、CRDT、人工）仍需另外决定。CRDT 与向量时钟的边界：向量时钟解决"检测并发/因果"，CRDT 解决"合并使收敛"。CRDT 结构内部常隐含类似版本向量的元数据（如每副本 ID + 时钟），用于保证操作/标签唯一，但 CRDT 的收敛性来自结构设计而非向量时钟。差异总结：CRDT ⊂ 能保证收敛的最终一致；向量时钟是"检测工具"，CRDT 是"合并工具"，二者互补。

最终一致是宽泛的收敛性质，CRDT 是保证收敛的具体实现；向量时钟只负责"检测因果/并发"，CRDT 负责"合并使收敛"。理解边界：CRDT 是"强收敛的最终一致"，向量时钟是"因果检测"而非"合并方案"。

• LWW 与 G-Counter 的冲突语义
• 状态复制（CvRDT）与操作复制（CmRDT）
• 核心概念体系

CRDT 的核心概念包括：冲突解决语义（如何合并并发操作）与复制方式（同步什么）。LWW（Last-Writer-Wins）：冲突解决语义——用时间戳/时钟决定哪个写入胜出，适合"覆盖语义"（单值寄存器），简单但丢失合并信息。G-Counter：冲突解决语义——单调增长计数器，用"每副本计数 + 逐分量 max"合并，适合"累加语义"。状态复制（state-based / CvRDT）：同步整个状态，合并用 join（并集、max），对乱序健壮但带宽大。操作复制（op-based / CmRDT）：同步操作，要求操作可交换，带宽小但依赖可靠通道。核心概念体系：1) 冲突解决：LWW（覆盖）、G-Counter/PN-Counter（计数）、集合（G-Set/2P-Set/OR-Set）、序列（RGA/YATA）；2) 复制方式：状态复制 vs 操作复制；3) 保证：幂等、交换、结合保证收敛。理解：LWW 与 G-Counter 是"冲突语义"的两种代表（覆盖 vs 累加），状态复制与操作复制是"同步机制"的两种代表（状态 vs 操作）。四个概念构成了 CRDT 设计的基本维度。

CRDT 的核心概念可归为两维：冲突语义（LWW、G-Counter 等）与复制机制（状态/操作）。前者决定"如何合并"，后者决定"同步什么"。LWW 与 G-Counter 体现"覆盖 vs 累加"的语义差异，状态/操作复制体现"带宽与容错"的权衡。

• CRDT 的 JSON 文档类型
• 富文本协同
• OT 与 CRDT 的工程差异

CRDT 的 JSON 文档：Yjs 用 Y.Map（键值映射）、Y.Array（有序列表）、Y.Text（可编辑文本）、Y.Xml/Y.XmlElement（富文本/XML）等组合表示任意 JSON 文档。Y.Map 的并发 set/last-write-wins 或按客户端 ID 排序，Y.Array 按 ID 排序，Y.Text 用 YATA 处理并发插入/删除。嵌套结构（Y.Map 包含 Y.Array 等）表示树形对象。富文本协同：Y.Text 支持富文本（加粗、颜色、链接），通过 Y.Text 的 formatting 属性（用 Y.Map 存储格式区间）实现；格式与文本的并发编辑需 CRDT 协调，保证格式与内容一致。OT 与 CRDT 的工程差异：1) 架构：OT 依赖中心服务器 transform，CRDT 去中心化、自动合并；2) 实现复杂度：OT 的 transform 复杂易错，CRDT 的合并简单但元数据多；3) 容错：OT 对乱序/丢包敏感，CRDT 健壮；4) 带宽：OT 操作小，CRDT 需携带 ID/墓碑；5) 文本：OT 传统用于文本（Google Docs），CRDT 逐渐用于富文本/结构化（Yjs、Figma）；6) 工程：CRDT 更易实现离线、多端、弱网，OT 在中心低延迟场景仍高效。结论：CRDT 用结构化类型覆盖 JSON 文档与富文本，工程上比 OT 更易实现去中心化与离线，但需管理元数据膨胀。

CRDT 的 JSON 文档用 Y.Map/Y.Array/Y.Text 组合表达结构，富文本用格式区间（Y.Text.formatting）实现。OT 与 CRDT 的工程差异体现在架构、复杂度、容错、带宽与离线支持。CRDT 更适合现代多端离线协同，OT 适合中心化低延迟。

• tombstone 保证删除收敛
• 因果稳定标签与压缩
• HLC/Lamport 时钟的作用

CRDT 的四个机制分别承担正确性与可压缩性：1) tombstone（墓碑）：删除不物理移除，而是标记，保证所有副本对"已删除"达成一致，避免删除传播不及时导致复活——保证正确性。2) 因果稳定标签（causally stable tags）：当某标签（操作）已对所有副本可见（因果稳定），就可安全地回收其墓碑/元数据用于压缩——它是"可压缩"的判定依据。3) 混合逻辑时钟（HLC）：为每个操作提供接近真实时间且保持因果序的时间戳，用于判断"谁先谁后"、保证因果序与 LWW 正确性，同时接近真实时间便于 debug——保证正确性。4) Lamport 时钟：提供单调递增的逻辑时间，保证因果序（若 a 因果先于 b 则 L(a)<L(b)），用于操作排序与因果判定——保证正确性。如何保证正确性：tombstone 保证删除收敛，HLC/Lamport 保证因果序与冲突判定，因果稳定标签保证回收不破坏收敛。如何保证可压缩：因果稳定标签（或版本向量确认）决定哪些墓碑/元数据已稳定可回收，配合 tombstone 清理与 delta 压缩，控制 CRDT 状态膨胀。关系：HLC/Lamport 提供时间与因果，tombstone 提供删除语义，因果稳定标签把"因果确认"与"回收"联系起来，实现正确性与可压缩的统一。

正确性来自"删除用墓碑 + 时间/因果用时钟 + 合并可交换"；可压缩性来自"因果稳定标签决定何时回收墓碑/元数据"。HLC 与 Lamport 提供因果与时间，tombstone 保证删除收敛，因果稳定标签是"安全压缩"的前提。四者配合让 CRDT 既正确又可控内存。

• CvRDT 与 CmRDT 的正确定义
• 幂等、交换、结合的证明
• 偏序合并与收敛

先澄清术语：CvRDT（convergent RDT，基于状态）与 CmRDT（commutative RDT，基于操作）。CvRDT（状态型）：状态是偏序集（join-semilattice）上的元素，合并 = join（最小上界）。证明：1) 幂等性：join 满足 x ⊔ x = x（取最小上界，与自身合并不变）；2) 交换性：x ⊔ y = y ⊔ x（最小上界定义对称）；3) 结合性：(x ⊔ y) ⊔ z = x ⊔ (y ⊔ z)（最小上界唯一）；4) 偏序合并：状态按 x ⊑ x ⊔ y 单调前进，合并后仍为偏序中的较"大"状态。只要状态保存在半格中且合并是 join，任意乱序合并收敛到全局最小上界。CmRDT（操作型）：操作是可交换的（apply(a, apply(b, s)) = apply(b, apply(a, s))），且幂等（apply(a, apply(a, s)) = apply(a, s)，配合同步框架）。证明：操作可交换则任意顺序应用结果一致；幂等则重复投递不改变结果；配合"至少一次 + 先序"的可靠传播，最终所有副本应用了相同操作集合，收敛到同一状态。总结：CvRDT 靠"join 的幂等/交换/结合"证明，CmRDT 靠"操作可交换 + 幂等"证明。两者都要求代数性质保证收敛，证明方式不同（状态合并 vs 操作应用）。

收敛性的证明核心是"合并（或应用）运算满足幂等、交换、结合"。CvRDT 用半格上的 join 满足这三性质，CmRDT 用可交换且幂等的操作满足这三性质。三性质保证任意乱序（或重复）合并/应用收敛到同一状态，这是 CRDT 正确性的数学证明路径。

• OT 的数学结构（transform 依赖）
• CRDT 的数学结构（可交换合并）
• 工程实现差异

数学结构端：OT 的收敛依赖"transform 函数"在操作间做变换，transform 需要满足复杂的性质（如 convergence、TP1/TP2 等），且 transform 的定义依赖操作上下文与类型，随操作类型增多而爆炸、难以证明正确；OT 还依赖操作顺序（需中心服务器/因果序），其数学结构是"操作变换 + 顺序依赖"，健壮性差。CRDT 的数学结构是"可交换合并（幂等/交换/结合）"，收敛性由代数性质直接保证，无需 transform、无需顺序，可以与任意并发操作合并，数学上更简单、更可证明。工程实现端：OT 需要中心服务器保持操作顺序，transform 实现复杂易错、对乱序/丢包敏感，离线/多端支持难；CRDT 去中心化、无需服务器、自动合并、容忍乱序/重放、天然支持离线与多端，工程实现更简单（无需写 transform 的复杂逻辑），且状态/操作可增量同步。结论：CRDT 在数学上用"可交换合并"规避了 OT 的 transform 复杂度与顺序依赖，在工程上去中心化、健壮、易离线，尽管元数据膨胀是代价，但整体上更简单可控，故逐渐取代 OT（尤其新应用）。

OT 的复杂度集中在"transform 正确性"与"顺序依赖"，CRDT 把复杂度转移到"数据结构与元数据"，但用代数性质保证收敛，去掉了 transform 与顺序依赖。工程上离线、多端、乱序容错让 CRDT 更实用。这是 CRDT 取代 OT 的根本原因。

• 从 OT 迁移到 CRDT 的要点
• 数据模型映射
• 回退机制与兼容

迁移经验：1) 数据模型映射：把业务对象映射为 CRDT 类型——画板图元用 Y.Map（属性）+ Y.Array（图层顺序），表格用 Y.Map（单元格）或专用表格 CRDT，PPT/设计稿用嵌套的 Y.Map/Y.Array 表达对象树与页面顺序；2) 保留唯一 ID：每个对象/元素分配稳定 ID，作为 CRDT 的唯一标识，避免迁移动态冲突；3) 格式与语义：富文本格式用 Y.Text.formatting，对象属性用 Y.Map 的 merge/last-write-wins，序列用 Y.Array 的 ID 排序；4) 增量同步：用 Delta 同步（Yjs 的 update）只传变更，降低带宽；5) 测试：用模拟时钟 + 随机重排验证收敛性，确保迁移后多端一致。回退机制：1) 双写/双轨：迁移期同时写 OT 与 CRDT，用 CRDT 作为最终一致源，OT 作为兼容层；2) 版本标记：给文档/操作打版本号，旧客户端（OT）用旧逻辑，新客户端（CRDT）用新逻辑，服务器按版本路由；3) 快照导入：迁移时把 OT 文档导出为 CRDT 快照（导入现有状态），新操作用 CRDT 更新，兼容旧只读数据；4) 回退到 OT：若 CRDT 出问题，可基于快照重建 OT 文档，或保留 OT 历史以便回滚；5) 分阶段：先只读、再单端写、最后全量 CRDT，降低风险。要点：迁移要保证 ID 稳定、语义一致、双轨兼容、可回退，避免数据丢失。

迁移经验的核心是"数据模型映射 + 稳定 ID + 增量同步 + 收敛测试"；回退机制的核心是"双轨/版本标记/快照"，保证迁移期间新旧客户端并存、可回退。画板/表格/PPT/设计稿都是结构化对象，适合用嵌套 CRDT 表达，迁移通用性强。

• 各端的使用场景
• 持久化与 provider 选型
• 性能与资源约束

Yjs 与 Automerge 的选型：两者都是成熟 CRDT 库，Yjs 性能好、提供商生态丰富（y-websocket、y-indexeddb、y-socket.io），Automerge 有 Rust 核心、适合嵌入式/大数据。Web 端：用 Yjs + y-websocket（或 y-webrtc）做实时同步，y-indexeddb 做本地持久化，支持离线与刷新恢复；适合浏览器协同编辑、白板。移动端：注意资源与网络约束——Yjs 有 JS 版可在 React Native/WebView 使用，Automerge 有 Rust 核心（automerge-rs）适合原生移动端（性能好、内存可控）；用本地持久化（SQLite/IndexedDB）+ 增量同步（delta）降低带宽；移动端网络弱，活用离线缓存与重连后的增量合并。桌面端：用 Automerge（Rust 核心）或 Yjs 嵌入桌面应用（Electron/Tauri），本地持久化到文件或 SQLite，支持离线编辑与多实例合并；桌面端内存/CPU 充裕，可用更大文档与更完整的功能。通用最佳实践：1) 用版本向量/增量同步控制带宽；2) 本地持久化 + 离线优先；3) 定期压缩/GC 控制状态膨胀；4) 用 provider 适配网络（WebSocket/WebRTC/HTTP）；5) 按平台选库（Web 用 Yjs 生态，原生/嵌入式用 Automerge Rust）。选型：协同编辑/白板生态丰富选 Yjs；嵌入式/大数据/原生性能选 Automerge。

选型看平台与需求：Web 端 Yjs 生态最成熟，移动端考量资源与网络（Automerge Rust 或 Yjs 轻量），桌面端用 Rust 核心或 Yjs 嵌入。通用实践是"本地持久化 + 增量同步 + 压缩 GC + provider 适配"。核心是"离线优先 + 自动合并"。

• 单元测试与收敛性断言
• 模拟时钟与随机重排
• 模糊测试与可用性测试

测试 CRDT 分三个层面：正确性（单一副本操作正确）、收敛性（多副本任意顺序合并一致）、可用性（性能与资源）。方案：1) 单元测试：对每个操作（increment、add、remove、insert）验证单一副本上的状态变化正确；对每个合并运算验证"幂等（合并自身不变）、交换（合并顺序无关）、结合（分批合并与整体合并一致）"三个性质；用中断性断言（如 G-Counter 合并后值等于两副本各自值之和）。2) 收敛性测试（模拟时钟 + 随机重排）：构造多个副本，各自应用一组随机操作（用模拟时钟控制时间与顺序），模拟"不同副本以不同顺序处理操作"，然后任意顺序合并所有副本，断言所有副本最终状态相等；对离线/重连场景，模拟副本离线时各自编辑、重连后合并，断言收敛。3) 模糊测试（Fuzz）：随机生成大量操作序列（各种插入/删除/合并排列），随机重排、重复投递、乱序到达，断言收敛性与不变量（如"文本内容一致""集合元素一致"）；用 property-based testing（如 QuickCheck/fscheck）断言幂等/交换/结合/收敛性质。4) 可用性测试：测量同步带宽、合并延迟、内存（墓碑增长）随操作数增长；GC 后验证不破坏收敛。要点：收敛性测试一定要覆盖"乱序、重复、离线、并发"四类场景，用随机重排 + 收敛断言是最有力的验证。

CRDT 正确性测试的本质是"验证代数性质（幂等/交换/结合）与收敛性"。单元测试验证单副本与合并性质，模拟时钟 + 随机重排验证多副本乱序收敛，模糊测试穷举并发场景。收敛性断言（所有副本最终状态相等）是最核心的测试目标。

• compaction 压缩状态
• snapshot 快照
• state-based delta merge 增量合并

CRDT 状态过大的根源是"操作历史 + 墓碑 + 元数据"累积。三种处理：1) compaction（压缩/合并）：把多条操作合并为更紧凑的形式（如把多个相邻操作合并、去除冗余元数据），降低状态体积但不改变语义。取舍：减少存储/传输，但需在"所有副本确认"后安全执行，否则破坏收敛；压缩有 CPU 开销。2) snapshot（快照）：把当前状态压缩为一份快照（记录"截至某时刻的完整状态"），替换此前的历史。取舍：快照后传输快、恢复快，但需保证所有副本都能基于快照 + 之后的增量收敛；快照本身是"压缩的历史"，合法性依赖因果稳定（快照前的操作已对所有副本可见）。3) state-based delta merge（基于状态的增量合并）：只合并"变更的增量状态"而非全状态，避免每次全量合并。取舍：降低带宽与合并开销，但需维护 delta 与版本的关系，若缺失增量需用完整状态补齐。取舍总结：compaction 面向"存储体积"（压缩操作），snapshot 面向"状态体积"（固化历史），delta merge 面向"传输带宽"（增量同步）。三者常组合：先确定因果稳定（所有副本已确认），再对稳定部分做 compaction/snapshot，随后用 delta 增量同步。权衡：aggressive 压缩省内存但需全局确认、CPU 高；保守则省 CPU 但状态膨胀。核心是"安全（所有副本确认）"与"效率（体积/带宽）"的平衡。

三种手段针对不同瓶颈：compaction 压缩存储、snapshot 固化历史、delta merge 优化传输。共同前提是"因果稳定"（副本已确认）才能安全回收/压缩，否则破坏收敛。取舍核心是"安全 vs 效率"：越激进越省资源但风险越高，需在确认安全的前提下做 compact/snapshot/delta。