Now vibe coding, so learning hammer FE ?https://channel.meo-ai.comhttps://channel.meo-ai.com/posts/711https://channel.meo-ai.com/posts/711Thu, 24 Sep 2026 12:31:04 GMT<span class="post-title-source">《Notion如何用CRDT解决并发编辑冲突》</span><br /><br />标签：<br /><a href="/search/result?q=%23%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F" title="#分布式系统">#分布式系统</a> <a href="/search/result?q=%23%E5%8D%8F%E5%90%8C%E7%BC%96%E8%BE%91" title="#协同编辑">#协同编辑</a> <a href="/search/result?q=%23CRDT%E7%AE%97%E6%B3%95" title="#CRDT算法">#CRDT算法</a> <a href="/search/result?q=%23%E6%95%B0%E6%8D%AE%E4%B8%80%E8%87%B4%E6%80%A7" title="#数据一致性">#数据一致性</a><br /><br />总结：<br /><br />文章要点：<br /><br />1. Notion在2025年重新设计了底层文本编辑系统，从"最后写入获胜"(LWW)模式转向基于CRDT的并发编辑方案，解决了多人同时编辑同一区块时的数据丢失问题。<br /><br />2. <mark class="highlight">CRDT</mark>(无冲突复制数据类型)允许多个客户端保留本地数据副本，并以确定性方式合并同时发生的更改，确保不会丢失任何人的修改。<br /><br />3. Notion使用的CRDT基于经典的RGA(可复制增长数组)序列CRDT，这是一个树形数据结构，每个字符都有唯一且稳定的ID，插入和删除操作都引用这些ID。<br /><br />4. 删除操作采用"墓碑"机制——标记项目为已删除但保留在树中，因为可能有在途或离线操作依赖于已删除字符的ID。<br /><br />5. 为提升存储效率，Notion将连续字符分组，为整组字符分配一个ID并存储运行长度，而不是为每个字符单独分配ID。<br /><br />6. 支持富文本格式需要解决注释冲突，Notion引入了基于Peritext算法的操作，支持可扩展和不可扩展的注释类型(如粗体vs超链接)。<br /><br />7. Notion的区块模型带来了独特挑战：当用户按下回车键分割区块时，需要处理文本在区块间移动时的并发编辑问题。<br /><br />8. 为解决这一问题，Notion引入了"文本切片"概念——每个区块的文本项属于一个文本切片，分割区块时切片也会相应分割并移动到新区块。<br /><br />9. 每个文本项ID由会话ID和Lamport时钟组成，确保ID的唯一性；指向同一原点的项目按逻辑时间戳排序，会话ID作为平局决胜因素。<br /><br />URL：<br /><a href="https://www.notion.com/blog/how-notion-handles-concurrent-editing-with-crdts" target="_blank" rel="noopener" title="https://www.notion.com/blog/how-notion-handles-concurrent-editing-with-crdts">https://www.notion.com/blog/how-notion-handles-concurrent-editing-with-crdts</a><a class="tgme_widget_message_link_preview" href="https://notion.com/blog/how-notion-handles-concurrent-editing-with-crdts" target="_blank" rel="noopener" title="Building a CRDT-based rich-text system that merges concurrent edits across Notion blocks—without losing anyone’s work"> <div class="link_preview_site_name accent_color">Notion</div> <img class="link_preview_image" alt="How Notion handles concurrent editing with CRDTs" src="/static/https://cdn4.telesco.pe/file/q84q8yLEOOmLTc0ofDVh85lGSkkH34LEWNUWMrHuBfa8DMVFJ70uPJOOE91WEi10t1DrhmFYqsXCh1NfU5hDlqL6-yqn4KkduyVHu_oxyCo84ZKtV4pGmbLs6tebPyW48imzpJhD0zBjXh0zjXYpH24aeEqdBxnY-baWgrjztdYEW1OCTR6C8sUFD3sE_7GA_YIMdh1-n2XV41pkqbnZCulJHntHA5-HoW6BP4SjHzBORFYzALteREU5YTaZQdwxavRRotbEdDRUxd9Gt1HRzT1Xk1zPBdCs5HUxAupip30-MXf3AHX9kObTW78Rco26_apNkgmvHdx0OvySIBASAw.jpg" width="1200" height="630" loading="eager" /> <div class="link_preview_title">How Notion handles concurrent editing with <mark class="highlight">CRDTs</mark></div> <div class="link_preview_description">Building a <mark class="highlight">CRDT</mark>-based rich-text system that merges concurrent edits across Notion blocks—without losing anyone’s work</div> </a>https://channel.meo-ai.com/posts/686https://channel.meo-ai.com/posts/686Mon, 27 Jul 2026 02:05:27 GMT<span class="post-title-source">《前端状态管理的真相与迷思》</span><br /><br />标签：<a href="/search/result?q=%23%E5%89%8D%E7%AB%AF" title="#前端">#前端</a> <a href="/search/result?q=%23Web%E5%BC%80%E5%8F%91" title="#Web开发">#Web开发</a> <a href="/search/result?q=%23React" title="#React">#React</a> <a href="/search/result?q=%23%E7%8A%B6%E6%80%81%E7%AE%A1%E7%90%86" title="#状态管理">#状态管理</a> <a href="/search/result?q=%23Redux" title="#Redux">#Redux</a> <a href="/search/result?q=%23Zustand" title="#Zustand">#Zustand</a> <a href="/search/result?q=%23Jotai" title="#Jotai">#Jotai</a> <a href="/search/result?q=%23MobX" title="#MobX">#MobX</a> <a href="/search/result?q=%23CRDT" title="#CRDT">#CRDT</a> <a href="/search/result?q=%23%E7%A6%BB%E7%BA%BF%E4%BC%98%E5%85%88" title="#离线优先">#离线优先</a> <a href="/search/result?q=%23%E5%AE%9E%E6%97%B6%E5%8D%8F%E4%BD%9C" title="#实时协作">#实时协作</a> <a href="/search/result?q=%23%E5%89%8D%E7%AB%AF%E6%9E%B6%E6%9E%84" title="#前端架构">#前端架构</a><br /><br />总结：<br />作者犀利指出，React生态中流行的"状态管理"库（Redux、Zustand、MobX等）本质上只是状态传播与通知系统，而非真正的状态管理。真正的状态管理必须包含时间维度与顺序概念，能正确应用变更并解决冲突。作者推荐转向Y.js、Zero、Fluid等基于CRDT或OT的时序感知系统，它们天然支持离线优先与实时协作，才是前端数据层的未来方向。<br /><br />文章要点：<br />1. 那些我们天天用的Redux、Zustand、MobX，本质上更像"消息广播员"而不是"状态管家"——它们能通知组件更新，却搞不定时间顺序和冲突解决<br />2. React自己也不是状态管理系统，整个前端圈把这个词用得太随意，导致大家一直在用错误的工具硬撑复杂场景<br />3. 真正的状态管理必须懂"时间"和"顺序"，就像分布式系统用向量时钟给事件排队，没有时间概念就谈不上管理<br />4. 值得庆幸的是，Y.js、Zero、Fluid这类基于CRDT和操作变换的工具已经相当成熟，它们天生会处理冲突，离线和实时协作都是顺手的事<br />5. 当我们把数据层从"发通知"升级到"管时序"后，离线优先和实时协作不再是昂贵的附加功能，而是正确架构带来的自然馈赠<br /><br />URL：<br /><a href="https://infrequently.org/2026/07/state-management" target="_blank" rel="noopener" title="https://infrequently.org/2026/07/state-management">https://infrequently.org/2026/07/state-management</a><a class="tgme_widget_message_link_preview" href="https://infrequently.org/2026/07/state-management" target="_blank" rel="noopener" title="It is by no means the gravest linguistic crime of the React epoch,1 but &quot;state management&quot; grates like nails on chalkboard. A Socratic dialogue I keep having about it goes something like this:"> <i class="link_preview_right_image" style="background-image:url('https://cdn4.telesco.pe/file/ikJwW7XtmRLraCtYYCU98eth1-gW6tZABXURyVahlK4DeVCx2q4ZW-GpUv8pXhNBJynRgGNB-8pkhsrRb1oOdMPFQ9GcwYYYJyKx2_246dZIbRuP0VVRejifERHTEtfMqvEthY27WJRAS-5Wqp9SkPcVI_XNkHWmd9yRkmPOS34i-e-SS9uL9QOozGTnezpHvhfM5LMkxZSmNck0D9I18sQk-Zm2znuBFHlMYkTb-9fCqRfwK06uTvUVyuukqZ0-Tl-WjUVPiPkQ5dnPfXTv0vtZR_nYDtwwUmkU8y5MXoNTGMq_ZpaG-xLuD_jur7PA4b1tP0iV01K4Xg9BXiefFQ.jpg')"></i> <div class="link_preview_site_name accent_color">Infrequently Noted</div> <div class="link_preview_title">The Absolute State of Management</div> <div class="link_preview_description">It is by no means the gravest linguistic crime of the React epoch,1 but "state management" grates like nails on chalkboard. A Socratic dialogue I keep having about it goes something like this:</div> </a>https://channel.meo-ai.com/posts/575https://channel.meo-ai.com/posts/575Wed, 18 Mar 2026 01:39:20 GMT<span class="post-title-source">《关于协作编辑的谎言（第二部分）：为什么我们不用Yjs》</span><br /><br />标签：<a href="/search/result?q=%23%E5%89%8D%E7%AB%AF" title="#前端">#前端</a> <a href="/search/result?q=%23ProseMirror" title="#ProseMirror">#ProseMirror</a> <a href="/search/result?q=%23CRDT" title="#CRDT">#CRDT</a> <a href="/search/result?q=%23%E5%8D%8F%E4%BD%9C%E7%BC%96%E8%BE%91" title="#协作编辑">#协作编辑</a> <a href="/search/result?q=%23%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96" title="#性能优化">#性能优化</a> <a href="/search/result?q=%23Yjs" title="#Yjs">#Yjs</a> <a href="/search/result?q=%23%E5%AE%9E%E6%97%B6%E5%8D%8F%E4%BD%9C" title="#实时协作">#实时协作</a><br /><br />总结：<br />本文是Moment.dev团队关于协作编辑算法分析的第二部分，作者详细阐述了为何在生产环境中放弃Yjs而选择基于ProseMirror-collab的简单方案。文章指出Yjs存在严重的性能问题（每次协作编辑会销毁重建整个文档）、与文档Schema冲突、权限控制困难、调试困难以及墓碑数据占用内存等问题。作者认为，除非真正需要无主节点的P2P架构，否则40行代码的"简单方案"在性能、可维护性和开发体验上都优于复杂的CRDT实现。<br /><br />文章要点：<br />- Yjs存在严重性能缺陷：每次协作编辑会销毁并重建整个文档，导致60fps目标难以达成，影响NodeView、插件状态、撤销功能和光标位置管理<br />- 简单方案仅需40行代码：使用prosemirror-collab库，通过单一权威节点管理文档版本和事务，支持乐观更新、离线编辑和网络中断恢复<br />- Yjs与文档Schema冲突：在无主节点架构下难以验证事务有效性，可能导致数据永久丢失，升级时尤其危险<br />- 权限控制复杂化：需要将Yjs的XML更新预测转换为ProseMirror事务来判断权限，实现难度大<br />- 墓碑数据问题：Yjs需保留删除标记，导致内存持续增长或数据丢失风险，而简单方案通过数据库存储步骤即可解决<br />- 调试困难：CRDT仅保证最终一致性，难以区分暂时分歧与真正错误，调试工具受限<br />- 核心观点：技术选型应从最终用户体验出发，而非算法本身；如无P2P刚需，简单方案在各方面均优于CRDT<br /><br />文章URL：<a href="https://www.moment.dev/blog/lies-i-was-told-pt-2" target="_blank" rel="noopener" title="https://www.moment.dev/blog/lies-i-was-told-pt-2">https://www.moment.dev/blog/lies-i-was-told-pt-2</a><a class="tgme_widget_message_link_preview" href="https://moment.dev/blog/lies-i-was-told-pt-2" target="_blank" rel="noopener"> <div class="link_preview_site_name accent_color">Lies I was Told About Collaborative Editing, Part 2: Why we don't use Yjs / Moment devlog</div> <img class="link_preview_image" alt="Lies I was Told About Collaborative Editing, Part 2: Why we don't use Yjs / Moment devlog" src="/static/https://cdn4.telesco.pe/file/YVXaUzBE8-9TDW2QQrSSbabfgg71zJ4YfK9str6-S1LPODRrO0GTgZm9XVC005_t5HR8VqdNrsgcUwQyA9CcsGyd1JTNXiYmfD35KPvxoWVvTV3w40qwfsqy8doKw0ZtWIufS8kkP6b_7C_qBXZmPDelkDueKKd_mZLaVGpRdnWPevjv76nE543DoXGcMtepNx9ppudeaLhaphSNg-17nX4wJVoKz43YqT9z_ynPXioKsnRqKvzAi1NxlO07pXRzyhwn5GcDxgfJ6WE6NlLa5PhPeeJh7VLRKBwCq1-crT8pqRc_IVTVDnEToydSWbK2EBXIWObDBA27HcLh3qeT-Q.jpg" width="1200" height="630" loading="eager" /> </a>