MarkIOYRead in EnglishMarkdown 中如何绘制图表
图表可以一直是文本：可在 Git diff 中审阅、可快速修改，只在读者需要时渲染成图形。Mermaid 是目前最适合从 Markdown 开始的方案。
从 Mermaid 代码围栏开始
Mermaid 图表使用语言标签为 mermaid 的代码围栏。围栏中的第一行声明图表类型。它是源码而不是图片，因此可以和解释它的文档一起检索、审阅和修改。
```mermaid
flowchart LR
A[起草] --> B[评审]
B --> C[发布]
```正在准备渲染效果…
LR 表示从左到右，TD 表示从上到下。选择和周围版面一致的方向；一个小图中尽量不要混用方向。
常用图表类型与语法
流程图：表达步骤与决策
```mermaid
flowchart TD
A[打开文档] --> B{可以发布了吗？}
B -- 是 --> C[导出]
B -- 否 --> D[继续编辑]
D --> B
```正在准备渲染效果…
方括号表示步骤，花括号表示决策。每个节点只放一个意思；流程图超过约十个节点时，应按职责或层级拆分。
时序图：表达交互发生的顺序
```mermaid
sequenceDiagram
participant 写作者
participant 编辑器
participant 文件
写作者->>编辑器: 编辑 Markdown
编辑器->>文件: 本地保存
文件-->>编辑器: 返回更新内容
编辑器-->>写作者: 渲染预览
```正在准备渲染效果…
->> 表示请求，-->> 表示响应。时序图负责解释沟通顺序，并不能取代实现层面的完整接口约定。
类图：表达概念与关系
```mermaid
classDiagram
class Document {
+String markdown
+save()
}
class Workspace {
+open(Document)
}
Workspace "1" o-- "many" Document
```正在准备渲染效果…
状态图：表达生命周期与转换
```mermaid
stateDiagram-v2
[*] --> 草稿
草稿 --> 评审: 提交
评审 --> 草稿: 修改
评审 --> 已发布: 通过
已发布 --> [*]
```正在准备渲染效果…
实体关系图：表达数据模型
```mermaid
erDiagram
WORKSPACE ||--o{ DOCUMENT : contains
DOCUMENT ||--o{ REVISION : has
WORKSPACE {
string name
}
DOCUMENT {
string title
string markdown
}
```正在准备渲染效果…
计划与概览类图表
| 类型 | 适合表达 | 第一行 |
|---|---|---|
| 甘特图 | 日期、里程碑与依赖 | gantt |
| 饼图 | 少量整体与部分的占比 | pie |
| 思维导图 | 探索概念树 | mindmap |
| 时间线 | 按时间排序的事件和阶段 | timeline |
```mermaid
gantt
title 发布计划
dateFormat YYYY-MM-DD
section 写作
草稿 :done, 2026-08-01, 3d
评审 :active, 2026-08-04, 2d
发布 :milestone, 2026-08-06, 0d
```正在准备渲染效果…
较完整的样例：文档流转
架构图可用 subgraph 把相关节点分组。标签说明意图，箭头说明数据或控制的方向；这比把每个内部细节都画上去更有用。
```mermaid
flowchart LR
Writer[写作者] --> Web[MarkIOY Web]
subgraph Browser[浏览器]
Web --> Source[Markdown 源码]
Source --> Preview[渲染预览]
end
Source --> Download[本地 .md 文件]
Download --> Git[Git 或其他编辑器]
```正在准备渲染效果…
先从这个概念层级开始。只有当另一类读者确实需要时，再添加一张说明技术依赖的图。一张图只回答一个问题。
兼容性与最佳实践
1. 在最终发布工具中检查支持
各产品和版本对 Mermaid 的支持并不一致。MarkIOY、许多文档工具和静态站点配置可以渲染它；普通 Markdown 查看器可能只显示源码围栏。请在最终目标中预览，并写一小段文字说明，确保不渲染时文档仍然能被理解。
2. 优先使用稳定、朴素的语法
节点 ID 使用 Editor 这样的简单名称，面向读者的文字放在方括号中。标签包含标点时按解析器要求加引号。除非确认所有目标渲染器都支持，否则不要依赖主题、定制 CSS 或最新语法。
3. 让源码也保持可读
统一缩进，每行只写一个关系，并使用有意义的 ID。图表源码也会进入代码审阅与 AI 检索；可读的源码比密集的箭头块更容易修改。
4. 只有在理由明确时才选择其他格式
团队已有 PlantUML 渲染器时可使用 PlantUML；Graphviz DOT 擅长图布局；手工绘制的插画则可能更适合 SVG 或图片链接。但它们并非 Markdown 核心能力：请放进带标签的代码围栏或链接生成结果，并说明渲染所需工具。
5. 让图表可访问
介绍图表时先写出结论，而不是只给标题；不要只靠颜色区分状态；重要关系要在附近文本中重复说明。图表应澄清文字，而不能承载唯一的决策信息。
把图表放在它解释的决策旁边
在 MarkIOY 中打开本地 Markdown，在源码视图加入 Mermaid 围栏，再用预览保持结构清晰。
打开 MarkIOY Web →