2014 年，瑞典开发者 Knut Sveidqvist 遇到了一个糟糕的问题：他精心制作的一张 Visio 流程图文件损坏了，无法打开。在绝望中，他看着女儿正在看迪士尼的《小美人鱼》，突然想到：如果图表也能用文本来描述，像代码一样管理，那该多好。

市面上图表库那么多，Chart.js、ECharts、D3、Highcharts、AntV、Plotly、Recharts、Victory… 选型时第一个要搞清楚的是：它们根本不是互相替代的关系。

前两篇聊了出图的历史和工具选型，这次落到技术底层：SVG、Canvas、WebGL 这三层渲染技术到底怎么选？ 很多人有个误解：SVG 最慢，Canvas 中等，WebGL 最快。就像交通工具的等级递进——自行车、汽车、飞机。但这种直觉是错的。

选技术之前，先看全貌。 很多人第一次接触前端可视化，直接就扎进某个框架的文档里，慢慢啃配置，最后做出来一个能跑的图表。但过几个月遇到性能瓶颈，或者需要支持更复杂的交互，才发现当初选的工具根本不合适。

本系列前面四篇文章层层递进，从 Gossip 的 Epidemic 传播理论，到 SWIM 的成员管理协议，再到 Rust 和 Go 语言的 P2P 实现，最后到 P2P 生产环境最佳实践——我们建立了一个完整的 Gossip 知识体系。

在前一篇文章中，我们深入探讨了 Gossip 协议的核心原理——Epidemic 传播模型、反熵与谣言传播的区别，以及 Phi Accrual 故障检测器的数学基础。Gossip 提供了一种通用的信息传播机制，但如果要构建一个完整的分布式集群，仅有信息传播是不够的：每个节点需要知道集群中还有谁——谁在线、谁已经离开、谁刚刚加入。

在 P2P 网络中，每个节点都需要在不依赖中心服务器的前提下，获取整个集群的状态信息——哪些节点在线、数据存储在何处、是否有新节点加入或旧节点离开。这个问题的本质是：在一个无法预测的、动态的网络中，如何高效且可靠地传播信息？

写博客一年多了，画了大概大几十张图。架构图、时序图、数据对比柱状图、TCP 拥塞窗口变化曲线。 然后有一天下班路上我突然意识到一件事：我每天都在用 Mermaid，但我完全不知道它背后是什么技术在画。

做工作室运维，最头疼的从来不是某个具体问题，而是设备多起来之后的「不知道」。 不知道哪个设备还活着，不知道它上面跑了什么服务，不知道网络里什么时候多了台新机器，不知道某个端口是不是还开着——这种「不知道」积累到最后就是故障。

内容写得再好，搜索引擎抓不到、搜不到，等于没写。这话说得有点重，但对绝大多数独立博客来说就是事实——你的服务器托管在某个 VPS 上、域名权重不高、外链稀少，Googlebot 可能一个月才来转一圈，而且每次来了看到的还是几周前的内容。读者在搜索框里输入的关键词，永远不会指向你的页面。一篇精心打磨的技术文章，最终只能躺在自己的归档页里吃灰。