流程图绘制要点：明确边界与逻辑分支

流程图是用来回答“这件事按什么顺序发生”的图。论文里常见的登录、审核、导出、支付、算法处理，都可以用流程图讲清楚。它不负责展示模块归属，也不负责说明数据表关系；它只关心控制路径：从哪里开始，经过哪些处理，遇到条件怎么分叉，最后在哪里结束。

如果一张流程图看起来像把开发任务逐条抄上去，通常不是节点少，而是边界没定好。画之前先写一句话：这张图只解释哪个业务场景。例如“导出论文图表流程图”只讲从用户发起导出到文件生成，不要顺手把登录、项目创建、模板管理都塞进去。

这张图由哪些东西组成

本工具的流程图由“节点”和“控制流”组成。节点表示流程中的动作、判断或特殊结构，控制流用 from -> to 表示方向，箭头后面可以加分支标签。

组件	DSL 写法	适合表达什么
开始 / 结束	开始 start: 开始、结束 end: 结束	流程入口和出口
处理	处理 save: 保存记录	普通业务动作
分支	分支 check: 是否通过?	需要“是/否”或多结果判断
输入输出	输入输出 form: 提交申请	表单、文件、接口输入输出
预定义过程	预定义过程 sync: 调用规则服务	被复用或外部封装的子流程
准备	准备 init: 初始化参数	流程前置准备
循环上界 / 下界	循环上界 retry: 是否重试?	循环检查和回退
并行	并行 forkBar、并行 joinBar	一入多出或多入一出的并行分叉 / 汇合

控制流可以这样写：

start -> form
form -> check
check -> approve: 是
check -> end: 否

也就是说，节点声明负责“图里有什么”，控制流负责“这些东西怎么走”。

后端会替你挡掉哪些乱图

后端不是只把文本画出来，它会检查图是否说得通：流程图必须且只能有一个开始节点，至少有一个结束节点；开始节点不能有进入箭头，结束节点不能继续输出；分支节点至少要有两条输出路径；并行节点只能作为“1 入多出”的分叉或“多入 1 出”的汇合使用。

这些限制看起来严格，但对论文有好处。评阅者最怕看到“开始节点有两个”“判断后没有去处”“箭头绕了一圈却没有结果”的图。工具提前报错，比你把一张逻辑不通的图放进论文里要好得多。

节点文案要短，解释放在正文里

流程图节点最好写成动宾短语：校验账号状态、生成导出文件、写入操作日志。不要把节点写成一整句话，比如“系统会判断用户输入的信息是不是正确的”。长句放进图里会挤，导出到 Word 后更容易糊。

正文里再补完整解释，例如：

用户提交账号密码后，系统先校验账号状态；账号存在且密码匹配时进入首页，否则返回错误提示并结束本次登录流程。该过程如图 3-2 所示。

这段话说明了主线和异常线，比“登录流程如下图所示”更像论文。

一张图只讲一个核心场景

流程图最容易膨胀。你可以保留主流程、影响结果的判断、必要的异常出口；不必把每一次按钮点击、每一次字段赋值都画进去。如果节点已经超过十几个，还越画越宽，通常应该拆成“总流程图”和“子流程图”。

常见拆法是：一张图讲“导出总流程”，另一张图讲“导出失败后的重试流程”；一张图讲“订单提交”，另一张图讲“支付回调”。拆开之后，正文也更容易写。

写进论文时怎么落笔

图题建议具体到场景，例如“图 3-2 图表导出流程图”，不要只写“流程图”。正文至少引用一次图号，并在图后解释两件事：主路径是什么，关键分支为什么这样处理。

定稿前可以按这几件事查一遍：是否只有一个开始节点；每个判断是否写清判断对象；分支箭头是否标注结果；异常路径是否有明确出口；图中术语是否和需求分析、功能设计一致。