流程图符号大全：起止/处理/判断/输入输出/数据/连接符怎么用

很多人第一次画流程图，卡的不是“不会画”，而是两件更具体的事：

• 同一件事到底该用“处理矩形”还是“输入/输出平行四边形”？
• 判断菱形画上去了，但分支条件写不清楚，最后整张图看起来像在猜谜。

流程图符号并不需要背大全；真正影响可读性的，是符号选择的一致性和写法的规范。这篇文章按“交付可用”为目标，把最常见的符号讲透，同时补齐你在项目里最容易踩的坑：分支怎么写、数据怎么标、跨页怎么连、怎么导出给别人看。

如果你手上是一段“文字步骤”，希望快速生成一张排版干净的流程图（并能导出 draw.io 或高清 PNG），可以直接用这个入口把文本喂给工具再微调：

• 流程图在线制作 - AI生成 | 自动排版

注：文中讲的是通用流程图（flowchart）符号习惯，不等同于 BPMN 的完整规范；但你照着做，画出来的图在产品、研发、运维、教学场景都能被快速读懂。

先给结论：90% 的流程图，靠 7 个符号就够了

你可以把流程图拆成 5 类信息：范围（开始/结束）、动作（处理）、分支（判断）、交互（输入输出）、存储（数据/数据库）、连接（连接符/跨页）。

最常用的 7 个符号就是：

1. 起始（Start）
2. 结束（End）
3. 处理（Process）
4. 判断（Decision）
5. 输入/输出（I/O）
6. 数据/数据库（Data/DB）
7. 连接符（Connector，含跨页/跨区）

“符号大全”真正的价值，不是堆满图形，而是告诉你：什么时候必须用它、用错会带来什么误读、怎么写才算合格。下面从这 7 个开始。

1) 起始 / 结束：把流程边界讲明白

起始（Start，常见是圆角矩形/椭圆）

什么时候用：

• 标记流程的入口（触发条件）
• 提醒读者“从哪里开始读”

推荐写法：

• 不要只写“开始”，最好带上触发：
  • “用户提交申请”
  • “定时任务触发（每天 02:00）”
  • “收到回调通知”

常见误用：

• 一个图里出现 3 个“开始”，但彼此不解释差异。若确实有多个入口，建议在标题或注释里说明“入口 A/B/C”，或者改用连接符把入口汇聚到同一处。

结束（End）

什么时候用：

• 标记流程终止的状态（成功/失败/中止/超时）

推荐写法：

• “结束：返回成功”
• “结束：提示错误（原因：库存不足）”
• “结束：进入人工处理队列”

注意：

• 一个流程可以有多个结束，但每个结束都要“像状态”一样清楚，避免出现一堆“结束”让人不知道到底结束在什么结果上。

2) 处理（Process）：所有“动作步骤”都归它，但名字要像动作

处理通常用矩形。

什么时候用：

• 系统执行的动作：写入、校验、计算、发送、生成
• 人做的动作也可以用处理（若不需要强调“手工/人工”区别）

命名规范（强烈建议）：

• 用“动词 + 宾语 + 必要的限定”
  • “校验验证码有效期”
  • “计算订单应付金额（含优惠）”
  • “写入支付流水”

避免：

• 只写名词：
  • “验证码” （这是数据，不是动作）
  • “用户信息” （这是数据，不是动作）
• 只写泛化动词：
  • “处理一下”“操作”“执行” （别人看不懂你到底干了什么）

一个实用小技巧：

• 如果你把每个处理节点都读成一句话，“系统/人 + 这个动作”，能顺畅读出来，基本就合格。

3) 判断（Decision）：菱形不是装饰，它要求你把条件写完整

判断通常用菱形。

什么时候用：

• 需要分支：是/否、成功/失败、满足/不满足、存在/不存在

分支写法（重点）：

• 判断节点本身写“问题/条件”，分支线上写“答案/结果”。

推荐：

• 判断节点： “验证码是否有效？”
• 出边标注： “是” / “否”

或者：

• 判断节点： “库存 ≥ 购买数量？”
• 出边标注： “是（继续下单）” / “否（提示缺货）”

硬规则：

• **每一条出边都必须有标签。**不标注就是让读者猜。
• 常见的两条出边：
  • “是/否”
  • “通过/失败”
  • “成功/失败”
  • “存在/不存在”

常见误用：

• 菱形里写“判断”，出边不写条件。
• 菱形里写一堆处理动作（把判断当成处理用）。
• 一个判断节点分出 4 条线，但没有清楚的互斥条件；这种情况更适合把条件拆成多个判断，或者用“多分支选择”表达（见后文扩展符号与写法）。

4) 输入/输出（I/O）：强调“交互/接口”，别跟处理混在一起

输入/输出常用平行四边形。

什么时候用：

• 用户输入：填写表单、输入验证码、上传文件
• 系统输出：展示结果、返回错误码、推送通知
• 与外部系统交互（你希望读者一眼看到“边界”）：调用第三方接口、接收回调

推荐写法：

• 输入类：
  • “输入：手机号 + 验证码”
  • “上传：发票图片”
• 输出类：
  • “输出：返回 200 + token”
  • “输出：提示错误（验证码过期）”

为什么要区分 I/O 与处理：

• 处理强调“系统内部做了什么”；I/O 强调“边界发生了什么”。
• 当你要做系统分析/接口联调/故障排查时，I/O 节点能迅速把“问题可能在谁那里”标出来。

5) 数据 / 数据库（Data/DB）：把“读写什么”说清楚，别只画个圆柱

数据/存储常见有两种画法：

• 数据/文件：可以是带底边的矩形、文档形状，或工具里的 Data 图形
• 数据库：最常见是圆柱体（DB）

什么时候用：

• 你希望读者知道关键数据落在哪里、流程依赖哪些数据
• 你在讲一致性/幂等/对账时，需要明确“写入发生在这里”

推荐写法：

• “读取：用户表（user）”
• “写入：订单表（order）”
• “更新：库存表（stock）”
• “记录：操作日志（audit log）”

常见误用：

• 画了 DB 圆柱，但不写表/集合/文件名，也不写读还是写。最后读者只知道“跟数据库有关”，不知道风险点在哪里。

一个更工程化的建议：

• 在数据节点里写“动作 + 数据对象”，而不是只写数据对象：
  • 不推荐：“订单表”
  • 推荐：“写入订单表（创建）”

6) 连接符（Connector）：它的作用是“降噪”，不是“让图更复杂”

连接符常见有：

• 同页连接符（小圆点/圆圈字母）
• 跨页连接符（Off-page connector，常用五边形/箭头形）

什么时候必须用连接符：

• 流程太长，线条交叉到难以阅读
• 需要跨页/跨区（例如从“用户端”跳到“后台系统”）
• 需要把相同子流程复用（例如“风控校验”在多个入口都会走）

连接符标注规则：

• 连接符要成对出现（A → A，或 1 → 1），且标注要唯一。
• 在连接符旁边写一句“去哪儿/从哪儿来”：
  • “A：跳转到【支付处理】段落”
  • “B：来自【异常处理】分支”

反例：

• 连接符只画一个不画配对。
• 连接符用来“偷懒”省略关键步骤（读者会以为你没想清楚）。

7) （扩展）子流程/预定义过程：当一个块太大，别硬塞进一个矩形

在实际项目里，流程往往会出现“一个步骤背后其实是十几个步骤”。这时你有两种更清晰的表达：

子流程（Subprocess）

常见画法是带双边线或带“+”的小标记。

什么时候用：

• 你在主流程里只想强调“这里会进入一段更细的流程”
• 你准备在另一张图里展开细节

推荐写法：

• “子流程：风控校验（见风控流程图）”
• “子流程：发票开具（见开票流程）”

预定义过程（Predefined process）

如果某段流程是团队里“约定俗成、反复复用”的标准步骤，可以用预定义过程强调它的可复用性。

注意：

• 这不是“模板库堆文本”。它表达的是“这是一个稳定可复用的模块”。

8) （扩展）文档 / 报表：当输出是“文件形态”时，用它更直观

文档符号通常是底部波浪的矩形。

适用：

• 生成对账单、导出报表、生成合同/发票 PDF
• 需要交付“文件”给人或系统

推荐写法：

• “生成：对账单 PDF”
• “输出：发票（PDF/电子发票号）”

9) （扩展）人工/手工操作：当你必须强调“人介入”，不要用普通处理糊过去

一些工具里会提供“手工输入/人工操作”的符号（例如梯形）。

什么时候值得强调：

• 审核、复核、人工客服处理
• 需要明确“这里不是自动化”，否则读者会误解系统能力

推荐写法：

• “人工审核：材料完整性”
• “客服处理：更改收货地址”

符号之外，更决定专业度的是：连线与布局规则

符号选对了，如果连线乱，图依然不可读。下面这些规则比“多认识几个符号”更值。

1) 统一方向：从上到下或从左到右，别来回折返

• 大多数中文读者习惯：从上到下。
• 只有在屏幕宽、需要泳道（角色）时，才考虑从左到右。

一个简单自检：

• 让别人从起始开始“用手指跟着读”。如果他经常需要回头找箭头，说明方向没统一。

2) 箭头必须清晰，线条尽量直角，减少交叉

• 箭头表示方向：没有箭头的线很容易被误读成“关联”而非“顺序”。
• 直角线更便于排版与跨区阅读。

3) 分支的默认习惯：是/成功放右边或下方，否/失败放左边或旁边

这不是硬标准，但团队内统一后，读者的阅读成本会显著下降。

4) 回路（循环）要写“退出条件”，否则像死循环

当出现“重试/循环”时，建议在回到前面之前加一个判断节点：

• “是否超过重试次数？”
• “是否超时？”

把“可退出”画出来，读者才知道这段循环是受控的。

只给 1 个小例子：用最少符号写出“可交付”的流程

下面这个例子刻意很短，只演示符号与条件写法（你不需要靠例子堆砌）。如果你有一段更长的文字步骤，建议直接用文本生成工具先出图，再按本文规范微调：

• 流程图在线制作 - AI生成 | 自动排版

开始 用户提交表单
用户提交表单 输入 校验字段
校验字段 判断 是否通过校验?
是否通过校验? -是 处理 写入数据库
是否通过校验? -否 输出 返回错误信息
写入数据库 输出 返回成功
返回错误信息 结束
返回成功 结束

你会发现：

• 判断节点是“问题句”，分支线是“答案”
• 输出节点明确“返回什么”
• 结束节点是“状态”，而不是空洞的“结束”

常见错误清单（对照改一遍，图会立刻变清晰）

1. 节点名全是名词：

• 错：“用户信息 → 订单信息 → 支付信息”
• 对：把每步改成动作：“读取用户信息 → 创建订单 → 发起支付”

2. 判断没有条件标签：

• 错：菱形分两条线，但线不写“是/否”
• 对：每条出边都写标签，必要时写“失败原因/后续动作”

3. 把外部交互画成内部处理：

• 错：“调用第三方支付”画成普通处理，读者看不出边界
• 对：用 I/O 或明显的边界标注，或在节点名里写“外部接口”

4. 数据库节点只画不写：

• 错：一个圆柱体叫“数据库”
• 对：写“读取/写入 + 表/集合/文件 + 关键字段（可选）”

5. 线条乱穿、交叉：

• 对：用连接符拆段；必要时把流程分成“主流程 + 异常流程”两张图

6. 异常分支不闭合：

• 错：失败分支一路飘到图外
• 对：失败分支也要回到某个结束状态，或明确进入“人工处理/重试队列”

什么时候不该用流程图？（以及该用什么）

• 你要描述“角色与事件驱动的时序”——更适合时序图（Sequence Diagram）。
• 你要描述“组织流程、泳道、事件、中间消息”——更适合 BPMN。
• 你只想列步骤，不需要分支/循环——用清单或 SOP 文档可能更快。

但如果你的目标是：把一个过程讲清楚，让别人能照着实现/验收/排查，流程图依然是最通用、成本最低的表达。

交付与导出：让别人打开就能用（而不是糊成一团）

流程图经常不是画给自己看的，而是要交付给：同事、甲方、老师、评审、客户或未来的自己。

导出前的最后检查

• 字体大小是否在 12–16 左右（打印/投屏可读）
• 线条是否有明显交叉导致误读
• 判断分支是否全都标注了条件
• 是否在图的角落写了“版本/日期/作者/范围”（可选但很有用）

导出格式怎么选

• 需要继续编辑、团队协作：优先 draw.io（或兼容格式）
• 需要发群里、写文档、贴到需求里：优先 PNG（建议 2x 或更高清）
• 需要打印或嵌入 PDF：可考虑 SVG/PDF（看工具支持）

如果你希望“从文本直接生成 + 自动排版 + 一键导出 draw.io/PNG”，这类场景用文本生成会比拖拽快很多：

• 流程图在线制作 - AI生成 | 自动排版

FAQ：关于流程图符号，你最可能会问的 8 个问题

Q1：流程图符号必须完全按某个国际标准吗？

不必。多数团队使用的是“行业习惯 + 工具默认”。关键是：同一张图内部一致、对读者无歧义。

如果你在做跨团队/对外文档，尽量靠近常见习惯（开始/结束、处理、判断、I/O、数据、连接符），可读性会更好。

Q2：判断节点一定只能两条分支吗？

不一定，但两条分支最清晰。多分支（例如 A/B/C）也可以做，但你要保证：

• 条件互斥且覆盖完整
• 每条分支都标注清楚

否则建议拆成多个判断，让读者一步步跟得上。

Q3：什么时候用“连接符”，什么时候把图拆成两张？

• 连接符适合：图还能在同一页/同一屏里读完，只是局部交叉太多。
• 拆图适合：主流程已经很长，或需要把“异常处理/重试/人工介入”单独讲。

经验上：当读者需要频繁缩放/拖拽才能读完整张图时，就该考虑拆图了。

Q4：I/O 平行四边形里要写“输入/输出”四个字吗？

不强制，但写上会更友好，尤其在图里同时出现“用户输入”“系统返回”“外部接口”时：

• “输入：……”
• “输出：……”
• “外部：调用 XXX API”

Q5：数据库圆柱体是不是只能表示数据库？缓存/队列怎么画？

圆柱体更多是“持久化存储”的视觉隐喻。缓存/消息队列也可以用数据存储类符号表示，但建议在节点名里直接写清楚：

• “写入：Redis 缓存（key=…）”
• “投递：MQ 队列（topic=…）”

比纠结形状更重要的是“读/写/投递/消费”动作明确。

Q6：流程图里要不要写错误码、字段名、SQL？

通常不建议写到流程图节点里（会让图变成代码块）。更好的方式：

• 节点里写“发生了什么”
• 细节放在注释/附录/链接文档里

只有当错误码本身是关键分支条件（例如不同错误走不同处理）时，才把它写在分支标签里。

Q7：泳道算不算“流程图符号”？

泳道更多是布局而不是节点符号，但它非常实用：当你要说明“谁负责哪一步”时，用泳道比用文字括号更清楚。

一个常见泳道划分是：用户端 / 业务服务 / 外部系统 / 数据库。

Q8：我只有一段需求文字，怎么最快变成一张看得懂的流程图？

最快的路径通常是：

1. 先把文字按“动作/判断/输入输出/数据”拆开，写成简短行
2. 用工具自动排版成图
3. 再按本文的命名与分支规范做一次清理

如果你想直接从文本生成并导出交付文件，可以用：

• 流程图在线制作 - AI生成 | 自动排版

最终检查清单（复制到你的脑子里就够了）

• 开始/结束写清楚触发与结果状态
• 处理节点都是“动词 + 宾语”，不写空泛词
• 每个判断的出边都有条件标签
• I/O 节点明确是输入、输出还是外部交互
• 数据节点写清楚读/写与数据对象
• 线条尽量不交叉，必要时用连接符或拆图
• 导出时保证清晰度（发文档用 PNG 2x，协作用 draw.io）

把这些做到位，你的流程图就不只是“画出来了”，而是能被别人拿去实现、拿去评审、拿去排查的工作产物。