PRD 和技术方案中常见的图及解读指南
PRD 和技术方案中常见的图及解读指南
本文面向初次接触产品需求文档（PRD）和技术方案的同学，系统介绍其中常见的 7 类图表——它们是什么、怎么看、怎么画、怎么用。每种图均附带一个通用示例，以"在线商城订单系统"为背景，方便理解。
目录
- 用例图（Use Case Diagram）
- ER 图（Entity-Relationship Diagram）
- 流程图（Flowchart）
- 时序图（Sequence Diagram）
- 状态图（State Diagram）
- 架构图（Architecture Diagram）
- 数据流图（Data Flow Diagram）
- 总结对比
1. 用例图（Use Case Diagram）
1.1 是什么
用例图是 UML 中用于描述系统功能边界的图。它回答一个核心问题：谁 使用系统的 哪些功能？
用例图常出现在 PRD 和技术方案的开头部分，用于快速对齐"这个系统/模块要做什么"。
1.2 基本元素
| 符号 | 名称 | 含义 | 画法 |
|---|---|---|---|
| 🧑 小人图标 | Actor（参与者/角色） | 与系统交互的外部实体，可以是人（如"买家"）也可以是外部系统（如"支付网关"） | 火柴人图标，标注角色名 |
| ⬭ 椭圆形 | Use Case（用例） | 系统提供的一个完整功能 | 椭圆内写功能名称 |
| ─── 实线 | 关联关系 | 参与者与用例之间的交互关系 | 实线连接 Actor 和 Use Case |
- - -> <<include>> |
包含关系 | 执行该用例时 必须 包含的子用例 | 虚线箭头，标注 <<include>>，从主用例指向子用例 |
- - -> <<extend>> |
扩展关系 | 在 特定条件下 才触发的可选子用例 | 虚线箭头，标注 <<extend>>，从扩展用例指向基础用例 |
| ──▷ 空心三角 | 泛化关系 | 参与者或用例之间的继承关系 | 实线 + 空心三角箭头 |
| 矩形框 | 系统边界 | 标识系统的范围 | 矩形框包围所有用例，标注系统名 |
M / S / C 标注 |
优先级标记 | M=Must（必须），S=Should（应该），C=Could（可选） | 写在用例旁 |
1.3 怎么看
- 先看参与者：左右两侧的小人是谁？理解有哪些角色在使用系统。
- 再看系统边界：矩形框内就是系统要做的事。
- 然后看用例：每个椭圆就是一个功能点，重点关注
<<include>>关系——它代表必须实现的子功能。 - 最后看优先级：M 标记的用例是 MVP 必须交付的。
1.4 怎么画
- 确定系统边界（画矩形框，写上系统名）。
- 列出所有参与者（放在边界外侧）。
- 识别核心用例（放在边界内部，每个功能一个椭圆）。
- 连线：参与者→用例用实线，用例之间的依赖用
<<include>>或<<extend>>。 - 标注优先级。
1.5 示例
场景：在线商城订单系统
┌─────────────────────────────────────────────────────────┐
│ 订单管理系统 │
│ │
│ ┌──────────────┐ │
│ │ 浏览商品 [M] │◄─────────────────┐ │
│ └──────┬───────┘ │ │
│ │ │ │
│ ┌──────▼───────┐ ┌────────┴──────┐ │
│ │ 下单购买 [M] │─include─►│ 地址管理 [M] │ │
🧑 │ │ └───────────────┘ │
买家 ─┤ │ │
│ │ │─include─►┌───────────────┐ │
│ └──────┬───────┘ │ 库存校验 [M] │ │
│ │ └───────────────┘ │
│ ┌──────▼───────┐ │
│ │ 在线支付 [M] │─extend──►┌───────────────┐ │
│ └──────────────┘ │ 使用优惠券 [S] │ │
│ └───────────────┘ │
│ ┌──────────────┐ │
│ │ 查看订单 [M] │ │
│ └──────────────┘ 🧑 │
│ 管理员 ─┤
│ ┌──────────────┐ │
│ │ 取消订单 [S] │ ┌───────────────┐ │
│ └──────────────┘ │ 订单审核 [M] │ │
│ └───────────────┘ │
│ ┌───────────────┐ │
│ │ 退款处理 [M] │ │
│ └───────────────┘ │
└─────────────────────────────────────────────────────────┘
解读要点：
- 买家和管理员是两个参与者，分别拥有不同的功能入口。
- "下单购买"必须包含"地址管理"和"库存校验"（
<<include>>），这意味着后两者是下单的前置必要步骤。 - "使用优惠券"是"在线支付"的扩展（
<<extend>>），只在用户有券时才触发。 [M]标记的是必须实现的核心功能，[S]是应该有但可延后的功能。
2. ER 图（Entity-Relationship Diagram）
2.1 是什么
ER 图（实体-关系图）用于描述数据模型——系统中有哪些实体（表），实体有哪些属性（字段），实体之间是什么关系。
ER 图常出现在技术方案的数据库设计章节，是后端开发建表的直接依据。
2.2 基本元素
| 符号 | 名称 | 含义 |
|---|---|---|
| 矩形 | Entity（实体） | 对应数据库中的一张表 |
| 椭圆 | Attribute（属性） | 实体的字段（现代 ER 图常直接写在矩形内） |
| 菱形 | Relationship（关系） | 实体之间的关联（现代 ER 图常用连线 + 标注替代） |
1 |
一对一 | 一条记录对应另一表的一条记录 |
1..* 或 1:N |
一对多 | 一条记录对应另一表的多条记录 |
*..* 或 M:N |
多对多 | 需要中间表来维护关系 |
| 下划线字段 | 主键（PK） | 唯一标识一条记录 |
FK 标注 |
外键 | 引用另一张表的主键 |
2.3 怎么看
- 先看实体（矩形/表）：了解系统有哪些核心数据对象。
- 再看关系线：关注
1:N和M:N——它们决定了表结构和查询方式。 - 然后看字段：重点关注主键、外键和业务含义不明确的字段。
- 注意中间表：
M:N关系通常会拆出一张关联表。
2.4 怎么画
- 识别核心业务实体（名词提取法：从 PRD 中提取关键名词）。
- 为每个实体列出核心字段，标记 PK/FK。
- 确定实体间关系和基数（1:1 / 1:N / M:N）。
- 用连线 + 基数标注连接实体。
2.5 示例
场景：在线商城订单系统的核心数据模型
┌──────────────────┐ 1:N ┌──────────────────┐
│ 用户表 │───────────────►│ 订单表 │
│──────────────────│ │──────────────────│
│ PK user_id │ │ PK order_id │
│ username │ │ FK user_id │
│ phone │ │ order_no │
│ email │ │ total_amount │
│ status │ │ status │
│ gmt_create │ │ gmt_create │
└──────────────────┘ └────────┬─────────┘
│
│ 1:N
▼
┌──────────────────┐ N:1 ┌──────────────────┐
│ 商品表 │◄───────────────│ 订单明细表 │
│──────────────────│ │──────────────────│
│ PK product_id │ │ PK detail_id │
│ name │ │ FK order_id │
│ price │ │ FK product_id │
│ category │ │ quantity │
│ stock │ │ unit_price │
│ status │ │ subtotal │
└──────────────────┘ └──────────────────┘
┌──────────────────┐
│ 支付记录表 │
│──────────────────│
│ PK pay_id │
│ FK order_id │
│ pay_channel │
│ pay_amount │
│ pay_status │
│ pay_time │
└──────────────────┘
解读要点：
- 一个用户可以有多个订单（1:N）。
- 一个订单可以包含多个订单明细（1:N），每个明细关联一个商品（N:1）。
- 支付记录表通过
order_id外键关联到订单表。 - 所有表都有
PK（主键），关联表有FK（外键）标注。
3. 流程图（Flowchart）
3.1 是什么
流程图是最常见的图表类型，用于描述业务流程或系统处理逻辑的执行步骤和分支。它回答"事情是怎么一步步走下来的"。
流程图在 PRD 中用于描述业务流程，在技术方案中用于描述核心算法或处理链路。
3.2 基本元素
| 符号 | 名称 | 含义 |
|---|---|---|
| ⬭ 圆角矩形 / 椭圆 | 开始/结束 | 流程的起点和终点 |
| ▭ 矩形 | 处理步骤 | 一个操作或动作 |
| ◇ 菱形 | 判断/决策 | 条件分支（是/否、满足/不满足） |
| ▱ 平行四边形 | 输入/输出 | 数据的输入或输出 |
| → 箭头 | 流向 | 步骤之间的执行顺序 |
| ─ ─ 虚线框 | 注释/说明 | 对某个步骤的补充说明 |
3.3 怎么看
- 从开始节点出发，沿箭头方向阅读。
- 遇到菱形就停下来思考：这里有几个分支？分别走向哪里？
- 关注异常分支：除了正常的"是"路径，"否"路径往往是系统需要处理的异常情况。
- 看是否有循环：箭头回指到前面的步骤说明有重试或轮询逻辑。
3.4 怎么画
- 确定流程的开始和结束。
- 列出主要步骤（矩形）。
- 标识决策点（菱形），画出分支。
- 用箭头连接所有步骤。
- 先画正常流程（Happy Path），再补充异常分支。
3.5 示例
场景：用户下单支付流程
┌───────────┐
│ 开始 │
└─────┬─────┘
▼
┌───────────┐
│ 用户提交订单 │
└─────┬─────┘
▼
◇────────────◇
│ 库存是否充足？ │
◇────────────◇
│是 │否
▼ ▼
┌───────────┐ ┌──────────┐
│ 锁定库存 │ │ 提示缺货 │
└─────┬─────┘ └────┬─────┘
▼ ▼
┌───────────┐ ┌──────────┐
│ 生成待支付 │ │ 结束 │
│ 订单 │ └──────────┘
└─────┬─────┘
▼
┌───────────┐
│ 调用支付网关 │
└─────┬─────┘
▼
◇────────────◇
│ 支付是否成功？ │
◇────────────◇
│是 │否
▼ ▼
┌───────────┐ ┌──────────────┐
│ 更新订单状态 │ │ 释放库存 │
│ 为"已支付" │ │ 标记订单"已取消"│
└─────┬─────┘ └──────┬───────┘
▼ ▼
┌───────────┐ ┌──────────┐
│ 通知卖家发货 │ │ 结束 │
└─────┬─────┘ └──────────┘
▼
┌───────────┐
│ 结束 │
└───────────┘
解读要点：
- 流程有两个核心决策点：库存校验和支付结果。
- 库存不足时直接结束，不会生成订单——这是个关键的业务规则。
- 支付失败后会释放库存，避免超卖——这是典型的补偿逻辑。
- 正常路径（Happy Path）是：提交→校验库存→生成订单→支付成功→通知发货。
4. 时序图（Sequence Diagram）
4.1 是什么
时序图描述对象/系统之间的交互顺序，强调消息的时间先后。它回答"谁在什么时候向谁发了什么消息"。
时序图是技术方案中最常用的图之一，用于表示 API 调用链路、服务间通信、前后端交互等。
4.2 基本元素
| 符号 | 名称 | 含义 |
|---|---|---|
| 矩形 + 竖线 | 生命线（Lifeline） | 一个参与交互的对象/服务/模块，竖线表示时间轴 |
| → 实线箭头 | 同步消息 | 发送请求并等待返回 |
| - -> 虚线箭头 | 返回消息 | 请求的响应 |
| →> 半箭头 | 异步消息 | 发送后不等待返回 |
| 窄矩形（激活条） | 激活（Activation） | 对象正在处理消息的时间段 |
alt 框 |
条件分支 | 相当于 if-else |
loop 框 |
循环 | 重复执行 |
opt 框 |
可选 | 满足条件才执行 |
4.3 怎么看
- 从上往下读（时间从上到下流动）。
- 从左往右看参与方：通常最左边是调用发起方（如前端/用户），最右边是最底层依赖（如数据库）。
- 实线箭头是请求，虚线箭头是响应：一来一回构成一次完整调用。
- 关注
alt/loop框：它们包含条件逻辑和循环逻辑。 - 注意异步消息：异步调用后发起方不会阻塞等待。
4.4 怎么画
- 确定参与交互的角色/系统（画生命线）。
- 按时间顺序画出消息（先画 Happy Path）。
- 标注同步/异步、请求/响应。
- 用
alt/loop/opt框标记分支和循环。 - 标注返回值和异常情况。
4.5 示例
场景：用户下单时的服务间调用时序
┌──────┐ ┌──────┐ ┌───────┐ ┌──────┐ ┌──────┐
│ 前端 │ │订单服务│ │库存服务 │ │支付服务│ │通知服务│
└──┬───┘ └──┬───┘ └──┬────┘ └──┬───┘ └──┬───┘
│ │ │ │ │
│ 1.提交订单 │ │ │ │
│───────────>│ │ │ │
│ │ │ │ │
│ │ 2.查询库存 │ │ │
│ │───────────>│ │ │
│ │ │ │ │
│ │ 3.库存数量 │ │ │
│ │<─ ─ ─ ─ ─ ─│ │ │
│ │ │ │ │
│ │ ┌─────────────────────────────┐ │
│ │ │ alt [库存充足] │ │
│ │ │ │ │
│ │ │ 4.锁定库存 │ │
│ │──│────────>│ │ │
│ │ │ │ │ │
│ │ │ 5.锁定成功 │ │
│ │<─│─ ─ ─ ─ ─│ │ │
│ │ │ │ │
│ │ │ 6.创建订单(待支付) │ │
│ │ │ ───────┐ │ │
│ │ │ │ │ │
│ │ │ <──────┘ │ │
│ │ │ │ │
│ 7.返回订单号│ │ │ │
│<─ ─ ─ ─ ─ │ │ │ │
│ │ ├─────────────────────────────┤ │
│ │ │ [库存不足] │ │
│ 8.提示缺货 │ │ │ │
│<─ ─ ─ ─ ─ │ │ │ │
│ │ └─────────────────────────────┘ │
│ │ │ │ │
│ 9.确认支付 │ │ │ │
│───────────>│ │ │ │
│ │ 10.发起支付 │ │ │
│ │────────────────────────>│ │
│ │ │ │ │
│ │ 11.支付结果 │ │ │
│ │<─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│ │
│ │ │ │ │
│ │ 12.异步通知卖家 │ │
│ │──────────────────────────────────────>│
│ │ │ │ │
│ 13.支付成功 │ │ │ │
│<─ ─ ─ ─ ─ │ │ │ │
│ │ │ │ │
解读要点：
- 参与方有 5 个：前端、订单服务、库存服务、支付服务、通知服务。
alt框表示库存充足和不足两种分支。- 步骤 12 是异步消息——订单服务通知卖家后不等待结果。
- 虚线箭头（
<─ ─ ─）是返回/响应，实线箭头（───>）是请求。 - 时间从上到下，可以清晰看到调用链路的先后顺序。
5. 状态图（State Diagram）
5.1 是什么
状态图描述一个对象在生命周期内经历的所有状态以及触发状态转换的事件。它回答"这个东西有哪些状态？什么条件下会从 A 变成 B？"
状态图常出现在技术方案中，用于描述订单状态机、审批流、工单状态等。
5.2 基本元素
| 符号 | 名称 | 含义 |
|---|---|---|
| ● 实心圆 | 初始状态 | 对象生命周期的起点 |
| ◉ 圆圈内实心圆 | 终止状态 | 对象生命周期的终点 |
| 圆角矩形 | 状态 | 对象当前所处的稳定状态 |
| → 箭头 + 标注 | 转换（Transition） | 标注格式：事件 [条件] / 动作 |
| 虚线分割 | 子状态 | 一个状态内部的细分状态 |
5.3 怎么看
- 找到初始状态（实心圆），了解对象从哪个状态开始。
- 沿箭头走，阅读箭头上的事件（触发条件）。
- 关注所有可能的出边：一个状态可能因不同事件转向不同状态。
- 找到终止状态，理解对象在什么情况下"结束"。
- 注意是否有回退路径：比如"已支付"能否退回到"待支付"？
5.4 怎么画
- 列出对象的所有可能状态。
- 画出初始状态和终止状态。
- 确定每两个状态之间的转换条件（事件 + 守卫条件）。
- 用箭头连接，标注事件。
- 验证：是否有状态是"死路"（进入后无法转出且非终止状态）？
5.5 示例
场景：订单状态机
用户提交订单
●─────────────────────►┌─────────┐
│ 待支付 │
└────┬────┘
┌───────────────┤
│ │
超时未支付 用户支付成功
│ │
▼ ▼
┌──────────┐ ┌─────────┐
│ 已取消 │ │ 已支付 │
└──────────┘ └────┬────┘
▲ │
│ 卖家确认发货
买家申请取消 │
(发货前) ▼
│ ┌─────────┐
├─────────│ 已发货 │
│ └────┬────┘
│ │
│ 买家确认收货
│ │
│ ▼
│ ┌─────────┐
│ │ 已完成 │──────► ◉
│ └────┬────┘
│ │
│ 买家申请退款
│ │
│ ▼
│ ┌─────────┐ 退款成功
│ │ 退款中 │──────────►┌──────────┐
│ └────┬────┘ │ 已退款 │──► ◉
│ │ └──────────┘
│ 退款被拒绝
│ │
│ ▼
│ ┌─────────┐
└─────────│ 已完成 │──────► ◉
└─────────┘
解读要点：
- 订单从
●（初始）开始，经过"待支付"→"已支付"→"已发货"→"已完成"是正常的 Happy Path。 - 超时未支付会自动转为"已取消"——这通常由定时任务触发。
- "已发货"之前买家可以申请取消，之后就不能了——这是关键业务规则。
- "已完成"后还可以发起退款，进入"退款中"状态，这是一个回退路径。
◉是终止状态，"已取消"、"已完成"、"已退款"都可以终止。
6. 架构图（Architecture Diagram）
6.1 是什么
架构图描述系统的整体结构和分层，展示各模块/服务之间的依赖关系和通信方式。它回答"系统由哪些部分组成？它们之间怎么协作？"
架构图常出现在技术方案开头，帮助团队理解系统全貌。架构图没有严格的 UML 标准，形式比较自由。
6.2 常见类型
| 类型 | 用途 | 特点 |
|---|---|---|
| 分层架构图 | 展示系统的层次结构 | 上层依赖下层，层间有清晰边界 |
| 部署架构图 | 展示系统的物理部署 | 标注服务器、网络、中间件 |
| 调用链路图 | 展示服务间的调用关系 | 箭头表示调用方向，标注协议（HTTP/RPC/MQ） |
| 应用架构图 | 展示业务模块划分 | 按业务域组织，标注模块职责 |
6.3 怎么看
- 先看分层：从上到下通常是"接入层→应用层→领域层→基础设施层"。
- 看箭头方向：箭头表示依赖或调用方向。
- 看通信协议：HTTP、RPC（HSF/Dubbo）、MQ（消息队列）代表不同的集成方式。
- 看外部依赖：识别第三方服务、中间件、数据库。
6.4 怎么画
- 确定系统边界（哪些是自己的，哪些是外部的）。
- 按职责分层或分域。
- 画出模块/服务，标注名称和核心职责。
- 用箭头表示依赖/调用关系，标注协议。
- 标注中间件、数据库等基础设施。
6.5 示例
场景：在线商城系统的分层架构
┌─────────────────────────────────────────────────────────────┐
│ 接入层 (Gateway) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌─────────────┐ │
│ │ Web 端 │ │ App 端 │ │ 小程序端 │ │ Open API │ │
│ └──────────┘ └──────────┘ └──────────┘ └─────────────┘ │
└────────────────────────┬────────────────────────────────────┘
│ HTTP / HTTPS
▼
┌─────────────────────────────────────────────────────────────┐
│ 应用服务层 (BFF) │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ 商品服务 │ │ 订单服务 │ │ 用户服务 │ │
│ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │
└────────┼──────────────┼──────────────┼──────────────────────┘
│ RPC │ RPC │ RPC
▼ ▼ ▼
┌─────────────────────────────────────────────────────────────┐
│ 领域服务层 (Domain) │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌──────────┐ │
│ │ 商品域 │ │ 交易域 │ │ 会员域 │ │ 支付域 │ │
│ └───────────┘ └───────────┘ └───────────┘ └──────────┘ │
└────────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 基础设施层 (Infrastructure) │
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌───────┐│
│ │ MySQL │ │ Redis │ │ MQ │ │ OSS │ │ ES ││
│ └────────┘ └────────┘ └────────┘ └────────┘ └───────┘│
└─────────────────────────────────────────────────────────────┘
解读要点：
- 系统分为 4 层，上层只能调用下层，不能反向依赖。
- 接入层处理多端适配，应用服务层编排业务逻辑，领域层封装核心业务规则。
- 标注了通信协议：接入层→应用层用 HTTP，应用层→领域层用 RPC。
- 基础设施层包含了数据库（MySQL）、缓存（Redis）、消息队列（MQ）等中间件。
7. 数据流图（Data Flow Diagram）
7.1 是什么
数据流图（DFD）描述数据在系统中的流转路径——数据从哪里来，经过哪些处理，存到哪里，输出到哪里。它回答"数据是怎么流动的"。
数据流图常出现在技术方案中需要描述数据链路的场景，如数据同步、报表生成、ETL 流程等。
7.2 基本元素
| 符号 | 名称 | 含义 |
|---|---|---|
| 矩形（双竖线） | 外部实体 | 系统外部的数据源或消费者 |
| 圆角矩形 / 圆形 | 处理过程 | 对数据的加工、转换、计算 |
| 开口矩形 / 双横线 | 数据存储 | 数据库、文件、缓存等 |
| → 箭头 + 标注 | 数据流 | 箭头标注数据内容 |
7.3 怎么看
- 找到数据源头（外部实体或数据存储）：数据从哪里产生？
- 沿数据流方向阅读：经过了哪些处理过程？
- 看数据存储：处理结果保存在哪里？
- 关注数据转换：每个处理节点对数据做了什么变化？
7.4 怎么画
- 识别外部数据源和数据消费者。
- 列出核心处理过程。
- 标识数据存储节点。
- 用带标注的箭头连接，标明数据内容。
- 先画顶层（Context DFD），再逐层细化。
7.5 示例
场景：订单金额计算的数据流转
┌──────────┐ ┌──────────┐
│ 前端页面 │ │ 财务系统 │
│ (外部实体) │ │ (外部实体) │
└────┬─────┘ └────▲─────┘
│ │
│ 购物车数据 结算报表数据
│ (商品ID,数量) (订单汇总,税额)
▼ │
┌─────────────┐ 商品信息 ═══════════════════
│ 1.0 │◄────────────── 商品数据库
│ 价格计算 │ ═══════════════════
└─────┬───────┘
│
│ 商品单价 × 数量
▼
┌─────────────┐ 优惠规则 ═══════════════════
│ 2.0 │◄────────────── 优惠规则库
│ 优惠计算 │ ═══════════════════
└─────┬───────┘
│
│ 折后金额
▼
┌─────────────┐ 运费模板 ═══════════════════
│ 3.0 │◄────────────── 运费模板库
│ 运费计算 │ ═══════════════════
└─────┬───────┘
│
│ 最终金额 (商品金额+运费-优惠)
▼
┌─────────────┐ ═══════════════════
│ 4.0 │──────────────► 订单数据库
│ 生成订单 │ ═══════════════════
└─────┬───────┘
│
│ 订单确认信息
▼
┌──────────┐
│ 前端页面 │
└──────────┘
解读要点：
- 数据从前端页面（外部实体）出发，经过 4 个处理过程，最终存入订单数据库。
- 每个处理节点都需要从数据存储中读取额外数据（商品信息、优惠规则、运费模板）。
- 箭头标注了数据内容，可以清晰看到数据在每个环节的变化：购物车数据 → 单价×数量 → 折后金额 → 最终金额。
- 最终还有一条数据流指向财务系统（另一个外部实体），说明订单数据会同步给财务。
8. 总结对比
| 图表类型 | 核心问题 | 适用阶段 | 常见位置 |
|---|---|---|---|
| 用例图 | 谁用系统的什么功能？ | 需求分析 | PRD 开头 |
| ER 图 | 系统有哪些数据实体和关系？ | 数据库设计 | 技术方案 · 数据模型章节 |
| 流程图 | 业务/系统的处理步骤和分支？ | 需求分析 & 详细设计 | PRD 和技术方案均有 |
| 时序图 | 各系统/模块间的调用顺序？ | 详细设计 | 技术方案 · 核心链路章节 |
| 状态图 | 对象有哪些状态和转换条件？ | 详细设计 | 技术方案 · 状态机章节 |
| 架构图 | 系统的整体结构和依赖关系？ | 概要设计 | 技术方案 · 开头 |
| 数据流图 | 数据如何在系统中流转？ | 详细设计 | 技术方案 · 数据链路章节 |
阅读建议
拿到一份技术方案时，建议按以下顺序看图：
- 架构图 → 理解系统全貌
- 用例图 → 理解系统边界和功能范围
- ER 图 → 理解数据模型
- 流程图 → 理解业务逻辑
- 时序图 → 理解系统间交互
- 状态图 → 理解关键对象的生命周期
- 数据流图 → 理解数据的流转路径
绘制工具推荐
| 工具 | 特点 | 适用场景 |
|---|---|---|
| draw.io / diagrams.net | 免费，拖拽式，导出格式多 | 所有类型的图 |
| PlantUML | 代码生成图，版本可控 | 用例图、时序图、状态图、类图 |
| Mermaid | Markdown 内嵌，GitHub 原生支持 | 流程图、时序图、ER 图、状态图 |
| Excalidraw | 手绘风格，轻量 | 架构图、概念图、白板讨论 |
| Figma / Sketch | 专业设计工具 | UI Mockup、高保真原型 |
| ProcessOn | 在线协作，模板丰富 | 流程图、架构图、思维导图 |
浙公网安备 33010602011771号