很多人第一次画流程图，卡的不是“不会画”，而是两件更具体的事：
同一件事到底该用“处理矩形”还是“输入/输出平行四边形”？
判断菱形画上去了，但分支条件写不清楚，最后整张图看起来像在猜谜。
流程图符号并不需要背大全；真正影响可读性的，是符号选择的一致性和写法的规范。这篇文章按“交付可用”为目标，把最常见的符号讲透，同时补齐你在项目里最容易踩的坑：分支怎么写、数据怎么标、跨页怎么连、怎么导出给别人看。
如果你手上是一段“文字步骤”，希望快速生成一张排版干净的流程图（并能导出 draw.io 或高清 PNG），可以直接用这个入口把文本喂给工具再微调：
流程图在线制作 - AI生成 | 自动排版
注：文中讲的是通用流程图（flowchart）符号习惯，不等同于 BPMN 的完整规范；但你照着做，画出来的图在产品、研发、运维、教学场景都能被快速读懂。
先给结论：90% 的流程图，靠 7 个符号就够了
你可以把流程图拆成 5 类信息：范围（开始/结束）、动作（处理）、分支（判断）、交互（输入输出）、存储（数据/数据库）、连接（连接符/跨页）。
最常用的 7 个符号就是：
起始（Start）
结束（End）
处理（Process）
判断（Decision）
输入/输出（I/O）
数据/数据库（Data/DB）
连接符（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生成 | 自动排版
开始 用户提交表单
用户提交表单 输入 校验字段
校验字段 判断 是否通过校验?
是否通过校验? -是 处理 写入数据库
是否通过校验? -否 输出 返回错误信息
写入数据库 输出 返回成功
返回错误信息 结束
返回成功 结束
你会发现：
判断节点是“问题句”，分支线是“答案”
输出节点明确“返回什么”
结束节点是“状态”，而不是空洞的“结束”
常见错误清单（对照改一遍，图会立刻变清晰）
节点名全是名词：
错：“用户信息 → 订单信息 → 支付信息”
对：把每步改成动作：“读取用户信息 → 创建订单 → 发起支付”
判断没有条件标签：
错：菱形分两条线，但线不写“是/否”
对：每条出边都写标签，必要时写“失败原因/后续动作”
把外部交互画成内部处理：
错：“调用第三方支付”画成普通处理，读者看不出边界
对：用 I/O 或明显的边界标注，或在节点名里写“外部接口”
数据库节点只画不写：
错：一个圆柱体叫“数据库”
对：写“读取/写入 + 表/集合/文件 + 关键字段（可选）”
线条乱穿、交叉：
对：用连接符拆段；必要时把流程分成“主流程 + 异常流程”两张图
异常分支不闭合：
错：失败分支一路飘到图外
对：失败分支也要回到某个结束状态，或明确进入“人工处理/重试队列”
什么时候不该用流程图？（以及该用什么）
你要描述“角色与事件驱动的时序”——更适合时序图（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：我只有一段需求文字，怎么最快变成一张看得懂的流程图？
最快的路径通常是：
先把文字按“动作/判断/输入输出/数据”拆开，写成简短行
用工具自动排版成图
再按本文的命名与分支规范做一次清理
如果你想直接从文本生成并导出交付文件，可以用：
流程图在线制作 - AI生成 | 自动排版
最终检查清单（复制到你的脑子里就够了）
开始/结束写清楚触发与结果状态
处理节点都是“动词 + 宾语”，不写空泛词
每个判断的出边都有条件标签
I/O 节点明确是输入、输出还是外部交互
数据节点写清楚读/写与数据对象
线条尽量不交叉，必要时用连接符或拆图
导出时保证清晰度（发文档用 PNG 2x，协作用 draw.io）
把这些做到位，你的流程图就不只是“画出来了”，而是能被别人拿去实现、拿去评审、拿去排查的工作产物。