直接回答：CRDT（无冲突复制数据类型）用数学结构保证：各副本可独立并发修改，任意顺序合并后收敛到同一状态——无需协调即最终一致。保证来自合并运算满足交换律、结合律、幂等律（半格 join）。两大族：基于状态（CvRDT，传全量或增量状态合并）与基于操作（CmRDT，广播满足交换律的操作）。
展开解析：主要类型按直觉递进：G-Counter（只增计数器）——每副本一个分量，合并取各分量 max，读取求和；PN-Counter——两个 G-Counter 一增一减；G-Set（只增集合）——合并即并集；2P-Set——增集加删集（墓碑），删除永久不可复活；OR-Set（observed-remove）——元素带唯一标签，删只删已观察到的标签，并发“删了又加”语义为加存活，是可用集合的主力；LWW-Register——时间戳取最后写，简单但时钟敏感；RGA/WOOT/Logoot——序列 CRDT，协同编辑（多人文档）的基础，处理“同一位置并发插入”的顺序歧义。工程现实：收益是离线可用与多活写入（手机本地改、恢复后自动合），代价是元数据膨胀（墓碑与标签持续堆积，要定期 GC 且 GC 需要协调——CRDT 的阿喀琉斯之踵）、语义受限（“库存不能为负”这类全局约束 CRDT 表达不了，需要边界 CRDT 或回到协调）。适用场景：协同编辑（Figma、Automerge、Yjs）、计数与状态聚合（Redis CRDT 企业版、Riak 数据类型）、多活会话状态。选型判断：能忍受“合并语义由数据类型定死”就用，需要自定义业务冲突逻辑（如审批流）就别硬套。
追问方向：OR-Set 的墓碑 GC 为什么需要协调？序列 CRDT 如何处理并发同位插入？
（约 500 字）