带过几届新人之后我发现一个规律能一口气把 for、while、do while 的语法写得滚瓜烂熟的人不少但真让他把这三段代码各自画成一张规范的流程图十个人里有七个会在回边的落点上出错——要么把回边拉回起止框要么把i塞进菱形里要么判断框上长出三根箭头。循环流程图看起来是最基础的图实际上它同时考验三件事你对循环执行顺序的理解、你对流程图符号语义的掌握、以及你有没有在实际项目里被评审挑过毛病。这篇内容就是把这三种循环的流程图画法一次讲透从执行模型到符号约定从单层循环到嵌套和 break/continue配可直接照着画的案例适合正在学 C 语言、Python、Shell 语法的同学也适合需要画软件工程流程图、写毕业设计文档、做逻辑梳理的开发者。1. 先把三种循环的执行模型拆开看再谈流程图怎么落笔画图之前必须先想清楚一件事流程图不是语法的翻译而是执行顺序的翻译。你画的每一个框、每一根箭头都对应运行时真实发生的一步。所以如果对三种循环先做什么、后做什么、什么情况下回到哪里没有清晰的心智模型画出来的图必然是错的。我习惯在纸上先写出执行步骤的编号序列再把这些编号按顺序摆成图形这个方法能规避掉八成的结构性错误。1.1 for 循环的三段式结构决定了判断框的位置for循环的完整形态是for (初始化; 条件; 步进) { 循环体 }它的执行顺序是初始化只执行一次然后进入条件判断条件成立则执行循环体循环体执行完后执行步进步进结束后再次回到条件判断如此往复直到某一次判断不成立整个循环结束。这里最关键的一点是初始化在循环之外步进在循环体之后、判断之前。很多人画图时把初始化和步进都塞进循环体内图看起来能跑但语义完全变了——初始化会被重复执行循环变量的值每次都被重置逻辑上直接变成死循环。所以画 for 的流程图第一件事就是把初始化这个处理框放在菱形判断框的前面并且让回边指向菱形而不是初始化框。1.2 while 循环把判断提到最前面初始化和步进都要人工负责while (条件) { 循环体 }的执行顺序更简单先判断条件成立则执行循环体循环体执行完回到条件判断。它没有语法层面的初始化也没有语法层面的步进这两件事全部由写代码的人在循环外和循环体内自行安排。反映到流程图上就是初始化框画在循环外部通常是起止框之后的第一个处理框步进框画在循环体内部的最后一步回边从步进框指向菱形判断框。这个结构其实和 for 的流程图高度相似区别只在于 for 的步进是语法强制的while 的步进是人为约定的所以 while 的图更容易漏掉步进框——漏掉之后条件永远为真图就变成了一个没有出口的死循环。1.3 do while 把循环体压到判断之前回边的终点随之改变do { 循环体 } while (条件);最特殊它先无条件执行一次循环体执行完之后才去判断条件条件成立就回到循环体开头再执行一次不成立就往下走。这决定了两个画图上的硬性差异第一判断框出现在循环体之后而不是之前第二回边的箭头必须指向循环体的第一个框绝对不能指向起止框。指向起止框意味着整个程序重新开始包括初始化都会被重做那是完全不同的语义。我在评审新人图的时候do while 的回边指错位置几乎是最常见的问题十张图里能挑出五六张。1.4 判断位置带来的连锁差异用一张表说清三种循环的差异不是零散的它们都由判断框在哪这一个因素推导出来。把差异整理成表格画图时对着核对比凭印象画要稳得多。对比维度forwhiledo while判断框位置初始化之后、循环体之前循环体之前循环体之后循环体最少执行次数0 次0 次1 次初始化位置语法强制图的循环体外手动写在循环体外手动写在循环体外步进位置语法强制循环体执行完紧接着手动写在循环体内手动写在循环体内回边终点判断框菱形判断框菱形循环体第一个处理框适用场景次数已知的遍历与计数次数未知、先看条件再决定必须先执行一次再判断典型错误步进画进菱形漏掉步进框回边拉回起止框这张表里最值得多看一眼的是循环体最少执行次数这一行。0 次和 1 次看起来只差一次但在实际业务里差别巨大用 while 写读取用户输入并校验如果第一次输入就是合法的循环体一次都不执行那输入框根本就不会弹出来换成 do while用户至少会被要求输入一次这才是符合直觉的交互。很多线上 bug 的根源就是这里选错了循环类型。2. 流程图的符号约定哪些框能随便用哪些框一步都不能错符号用错图就是错的哪怕逻辑再正确也没法通过评审。国家标准的流程图符号体系里常用的其实就这么几种但每一种背后都有明确的语义边界混用会让读图的人产生错误预期。我见过有人用圆角矩形表示处理、用矩形表示起止图能看懂但放到正式文档里就是不规范的。这一章的规则不复杂但请务必钉死在脑子里因为后面所有案例都建立在这套约定之上。2.1 六种基本图形各自承担什么语义起止框圆角矩形或椭圆代表流程的开始和结束框内文字一般是开始结束或StartEnd。一张流程图有且只有一个主起止入口可以有多个结束出口比如异常分支、break 分支。处理框直角矩形代表一步计算或赋值比如sum sum i、i 1、i。所有改变数据状态的动作都放这里。判断框菱形代表一个能回答是/否的命题比如i 100、还有下一个元素。菱形里只能写条件表达式绝不能写赋值语句。输入输出框平行四边形代表与外部交换数据比如输入 n、输出 sum、读取一行。虽然写进处理框程序也能跑但在文档里区分开更专业。连接点小圆圈用于跨页或跨区域连接流程线嵌套循环里尤其有用。流程线带箭头的实线表示执行方向。回边、分支边都靠它表达。把这六种框和它们的用法列清楚之后你会发现流程图其实是一门约束性语言——它的表达能力有限正是这种有限性让逻辑无处藏身任何含糊都会暴露成图形上的不规范。2.2 判断框的两条铁律判断框是整个循环流程图里信息密度最高的地方它有两条不能破的规矩。第一条一个菱形只有一个入口、两个出口出口分别标注是和否或 Y/N、True/False。如果你发现一个菱形需要三个出口说明这个判断应该拆成两层或者后面接了 switch 类的多分支结构。第二条菱形里写的内容必须是命题必须能被判定真假不能出现i、sum i这类动作描述。我见过最典型的错误是把 for 的整个头部i 1; i 100; i抄进一个菱形这种图读起来毫无意义因为读者无法判断是和否分别走哪条路。2.3 回边才是循环流程图的灵魂普通顺序结构的流程图箭头一路向下就完事了一旦出现循环图里就会多出一种向上走的边这就是回边。回边画得好不好直接决定图能否被正确理解。三条经验回边一律从循环体的最后一步出发for 是从步进框出发while 是从循环体末尾的处理框出发do while 是从判断框的是分支出发回边必须与向下的主干线在视觉上区分开通常走图的左侧或右侧竖直通道不要贴着中间的框回边的终点必须是判断点do while 除外它指向循环体首框指向别处都会改变语义。实际画图时我习惯把所有回边统一靠右走这样一张图里向上走的线一眼就能数出来嵌套层数也就一目了然。3. for 循环流程图初始化与步进该放在循环外面还是里面这一章用真实的代码案例把 for 的流程图一步步搭出来。之所以从一个最朴素的累加案例开始是因为它包含了 for 循环的全部结构性要素初始化、判断、循环体、步进、回边一个都不少。把这一个画对了后面无论是遍历数组、处理字符串还是嵌套循环都只是在骨架上加东西。3.1 C 语言经典 for 到图形的映射过程先看代码这是求 1 到 100 的和int sum 0; for (int i 1; i 100; i) { sum i; } printf(%d, sum);按执行顺序拆解得到七个步骤sum 0i 1判断i 100成立则sum sum ii回到判断不成立则输出sum并结束。把这七步翻译成图形节点顺序如下表顺序图形框内文字出边指向1起止框开始节点 22处理框sum 0节点 33处理框i 1节点 44菱形i 100 ?是到节点 5否到节点 75处理框sum sum i节点 66处理框i i 1回节点 47输入输出框输出 sum节点 88起止框结束无这里有两个位置必须反复确认节点 3 的i 1在菱形之外节点 6 的i i 1在循环体内但在回边之前。如果哪天你画的图里i 1出现在节点 5 和节点 6 之间那这张图的逻辑就是错的因为每次循环都会把 i 重置成 1条件永远成立。3.2 Python 的 for 其实是迭代器循环图要跟着变形Python 里写for i in range(1, 101)语法上看着像 C 的 for但底层机制完全不同它是在遍历一个可迭代对象没有显式的初始化变量和自增操作。所以硬套 C 的模板去画 Python 的 for 流程图会画出一个看不见的 i图里凭空多出一堆没写过的框。正确做法是把判断框写成还有下一个元素循环体首步是取出当前元素赋给 itotal 0 for i in range(1, 101): total i print(total)对应的图形顺序是起止 →total 0→ 菱形迭代器中还有元素→ 是取出元素i 当前元素→total total i→ 回菱形 → 否输出 total → 结束。注意回边依然指向菱形因为 Python 的 for 本质上就是先判断有没有下一个再取出来处理和 while 的结构是同构的。这一点想通了你看 Python 的 for 和 while 就不会再有割裂感。3.3 Shell 与增强 for 的画法差异Shell 脚本里的循环写起来很不一样sum0 for i in $(seq 1 100); do sum$((sum i)) done echo $sum它同样是遍历式的$(seq 1 100)会先生成一个序列然后 for 依次取出每个值赋给 i。画图时判断框写序列中还有未取出的值循环体内先取下一个值赋给 i再累加。Java、C# 的增强 for 循环、C 的 range-based for 也是这个套路判断框统一写成还有下一个元素不要写成i 100因为你在图里根本没有暴露 i 的增长过程写条件表达式反而会自相矛盾。另外 Shell 是一种命令式文本环境输入输出框在它的流程图里用得比其他语言多读文件、打印结果、执行命令都适合画成平行四边形这样图的层次会更清楚。4. while 循环流程图判断前置结构下最容易漏掉的两根线while 是三种循环里最诚实的一种——你写什么它执行什么没有任何语法糖帮你兜底。好处是省心坏处是所有责任都落到写代码的人身上。画 while 的流程图时只要记住初始化在圈外、步进在圈内、回边指菱形这三句话基本不会错。但每年总有大量的人栽在同一个地方循环体里忘了写让条件趋向结束的那一步。4.1 从 while 累加案例拆一遍完整画法同样求 1 到 100 的和用 while 改写int i 1, sum 0; while (i 100) { sum i; i; }拆成步骤是i 1sum 0判断i 100成立则sum ii回判断不成立则输出。图形节点顺序为起止 →i 1→sum 0→ 菱形i 100 ?→ 是sum sum i→i i 1→ 回菱形 → 否输出 sum → 结束。和 for 的图放在一起对比你会发现while 的图只差两点初始化两个框的位置由语法决定变成了人为摆放步进框从语法保证存在变成了全靠自己记得写。我通常建议初学者把 for 和 while 的图并排画在同一个本子上差异一眼可见比背十遍笔记都管用。4.2 边界条件在菱形里到底该怎么写菱形的写法直接决定循环执行多少次这是最容易被忽略的细节。i 100执行 100 次i 100执行 99 次。别小看这一次的差别我在实际项目里见过因为边界写错导致分页少查一条记录、日志漏掉最后一行、数组越界一个元素的真实故障。画图时的习惯做法是在菱形旁边用铅笔标注一行小字写明这个条件成立时的取值范围和循环执行次数比如i 取 1 到 100共 100 次。正式文档里不好加批注那就画完之后自己按图跑一遍脑中推演把初始值代进去确认第一次能不能进循环再把终止前的值代进去确认最后一次能不能进。4.3 死循环与 while(1) 的标注方式有些循环本来就是要一直转下去的比如服务主循环、单片机扫描循环、命令行程序的事件循环。这时候条件恒为真while (1)或while (true)流程图里会画出一个永远走是分支的菱形。这种情况下不要傻乎乎地画一个没有否出口的菱形规范做法是保留两个出口把否分支连到一个真正的结束框或者直接不画线同时在菱形旁边加一个注释框写明由内部 break 或外部信号终止。如果循环体内有if (...) break;那就必须把 break 的箭头明确画出来指向循环之后的第一个框。图里只要出现了恒真菱形就一定要有明确的退出路径否则读图的人会认为这张图有 bug。5. do while 循环流程图回边为什么必须指向循环体第一框do while 是三种循环里画错率最高的一种原因很直接——它的图形结构和另外两种不太一样判断框跑到了后面回边的方向也变了。很多人画图时是肌肉记忆式地把回边拉回菱形结果画出来是 while 的图只是框的顺序被调换了逻辑上完全说不通。5.1 至少执行一次这个特性怎么落到图上看代码int score; do { printf(请输入成绩(0-100): ); scanf(%d, score); } while (score 0 || score 100);执行顺序是先显示提示语再读取输入然后判断成绩是否越界越界就回到显示提示语这一步重新来合法就继续往下。翻译成图形起止 → 输出请输入成绩 → 输入 score → 菱形score 0 || score 100 ?→ 是回边指向输出请输入成绩框 → 否往下走。请特别注意回边箭头的落点——它落在循环体的第一个处理框上而不是起止框。如果落在起止框意味着整个程序重启初始化、资源申请全部重做这在语义上完全是另一回事。5.2 输入校验与菜单驱动两个高频场景do while 的典型应用场景有两类。第一类是输入校验就是上面那个例子你必须先让用户输入一次才能判断他输得对不对先判断再输入在物理上就说不通。第二类是菜单驱动比如控制台程序显示1. 查成绩 2. 改密码 0. 退出用户选 0 才结束。它的流程图结构是起止 → 输出菜单 → 输入选项 → 判断选项是否为 0 → 是结束否执行对应功能 → 回到输出菜单。这里回边同样指向第一个处理框。这两类场景有共同特征动作必须发生一次以上才有意义且动作本身是判断条件的数据来源。只要满足这个特征就应该优先考虑 do while而不是硬用 while 加一个先行的重复代码块去凑。5.3 break 与 continue 在 do while 里的落点这两个语句在三种循环里的含义一致但在 do while 的图里落点有讲究。break的箭头应该直接指向循环结束后的下一个框跨越整个回边不要画成回到判断框。continue在 do while 里的语义是立刻跳到条件判断而不是跳到循环体开头所以箭头应该指向菱形判断框。很多资料画 continue 时统一画成回边这是不对的——在 while 和 for 里continue 的落点分别是判断框和步进框在 do while 里是条件判断三者都需要区分。如果一张图里同时出现 break 和 continue建议用不同线型或在线旁标注文字避免读者分不清哪根是哪根。6. 同一道题三种画法把差异摆在一起看才记得住光看单张图永远记不牢真正让人形成肌肉记忆的方法是同一个需求用三种循环各画一遍然后把三张图摆在一起对照。差异会自己跳出来不需要你额外背。这一章挑两个最具代表性的题目把三种画法的核心节点列出来。6.1 求和题的三种图形骨架对照需求是求 1 到 n 的和n 由用户输入。三种循环的图形骨架对照如下环节for 画法while 画法do while 画法输入 n起止后首个平行四边形同左同左初始化变量处理框 i1, sum0处理框 i1, sum0处理框 i1, sum0判断框位置初始化框之后初始化框之后循环体累加之后循环体内容sumsumisumsumisumsumi随后 ii1步进位置循环体之后、回边之前循环体末尾循环体末尾回边终点判断框判断框循环体首框从这张表能看出一个很重要的规律当循环至少需要执行一次时do while 的图会比其他两种更紧凑因为它把判断挪到后面去了。但如果循环次数可能为 0比如 n 为 0 时不求和do while 就错了它至少会加一次结果就多加了 1。这种0 次 vs 1 次的判断才是选循环类型时最该花时间想清楚的问题比纠结画法本身重要得多。6.2 菜单驱动的三种写法对比以显示菜单 — 选择功能 — 执行 — 回到菜单为例。用 while 写需要把显示菜单写两遍一遍在 while 之前一遍在循环体末尾流程图里就会出现两个内容完全相同的平行四边形看起来重复且容易改漏一处。用 do while 写只需要一个显示菜单框图干净很多。用 for 写则更别扭你很难在语法上表达用户不选退出就一直循环这件事通常只能写成for (;;)配上内部的 break这时候图里会出现一个恒真菱形加一根 break 箭头反倒比 do while 复杂。结论很明确这种先做再判断的场景do while 的图结构最简、最不容易出错评审时也最容易让人一眼看懂意图。6.3 把两张图并排贴在文档里的技巧如果你在写毕业设计或技术文档需要同时展示三种循环的差异建议按for 左、while 中、do while 右横排三张图使用完全一致的框尺寸、字号和颜色只在关键差异处判断框位置、回边终点用加粗边框或深浅不同的填充色区分。三张图对齐之后读者扫一眼就能看出差异所在比写一大段文字解释有效得多。如果版面限制只能竖排那就把三张图的判断框用同一条水平虚线贯穿对齐视觉上依然能形成对照关系。7. 循环流程图常见的九种画错方式与排查顺序画错了不可怕可怕的是不知道错在哪。这一章把我在代码评审和文档评审中反复见到的问题归成三类并且给出一套按顺序执行的排查方法。你可以把它当成一份自检清单每次画完循环流程图之后照着过一遍两分钟就能筛掉大部分低级错误。7.1 结构类错误回边、初始化、步进回边指向起止框这是头号错误会让初始化被重复执行初始化画进循环体内同上步进框缺失或位置不对在 for 里表现为步进跑到回边之后那样永远执行不到在 while 里表现为压根没画直接变成死循环循环体的第一个框被回边越过在 do while 里表现为回边指到了第二个框。这四类错误的共同点是可以纯靠结构检查发现不需要理解业务逻辑。我的检查方法是用手指顺着箭头走两遍第一遍走条件成立的路径看能不能回到该回的地方第二遍走条件不成立的路径看能不能正常走出去。7.2 语义类错误条件表达式与循环变量菱形里写了赋值语句比如i i 1这属于图形语义错误判断条件和实际代码不一致写代码是i n画图写成i n循环变量在循环体内被意外修改但图中未体现比如循环体里有个i i 2画图时只画了i图上和代码就对不上了累加变量忘记初始化就参与运算代码里有隐患图上也没体现初始化框评审时会被直接打回来。这类错误需要拿代码和图逐行对照建议在画完图之后反向把图读成伪代码再和原代码比对效率比正向核对高。7.3 嵌套循环与 break/continue 的处理方式嵌套循环的图不要画成一堆交叉的箭头那样谁也看不懂。规范做法是内层循环先用一个处理框占位在单独的一张子图里画内层循环的细节主图里通过连接点或子流程框引用它或者用内外两条不同侧的回边通道外层走最右侧内层走内侧视觉上分层。break 和 continue 的处理前面说过关键是落点break指向循环之后的框continue在 for 里指步进框、在 while 里指判断框、在 do while 里指判断框。嵌套场景下break 只跳出最内层所以箭头只能跨过最内层的回边千万不能画成一下子跳到最外层之后那是 return 或带标签的跳出。7.4 一套两分钟自检流程画完图后按这个顺序走第一步看起止框确认只有一个人口第二步找所有菱形逐个确认只有两个出口且框内是命题第三步顺箭头走一遍成立路径确认回边落点正确第四步走一遍不成立路径确认能到结束框第五步把图翻译成伪代码和原代码对照第六步检查所有处理框里的变量是否都在使用前被初始化过。这六步做完一张规范的循环流程图基本就成型了。我个人的习惯是把这六步写在便利贴上贴在显示器边上画完一批图之后统一过一次比画一张查一张要快。8. 绘图工具与排版细节让图能直接贴进文档图画对了只是及格能不能直接贴进技术文档、能不能黑白打印、能不能让同事一眼看懂是另一层功夫。这部分看起来是美化实际上影响着图的可用性尤其在需要提交评审或者写论文的场合规范的排版能省掉大量来回修改的时间。8.1 工具选择要按场景来定不同的绘图工具适合不同的场合。在线协作类工具如 ProcessOn、draw.io 网页版适合团队一起看、一起改拖拽顺手模板多缺点是复杂图容易卡桌面类工具如 Visio、draw.io 桌面版适合画大型、多页的图文件本地保存排版精度高适合正式交付Office 内置形状适合已经用 Word 写文档、图不多的情况好处是不用切换软件、粘贴后仍然可编辑缺点是画复杂图会很累纸笔加拍照适合想逻辑的阶段我到现在还保留着先手绘草图再用工具重画的习惯草图上改十遍的成本比软件里改一遍低得多。另外提醒一句很多工具提供代码转流程图的功能自动生成的图逻辑通常是对的但框的位置、线的走向往往很乱还需要手工调整别指望一键出成品。8.2 排版上必须遵守的几条硬规矩同层级的框必须同一尺寸、同一字号不要出现一个菱形大一个菱形小的情况同一水平线上的框必须严格对齐差几个像素在打印稿上非常刺眼回边统一走一条侧向通道不要一根在左一根在右箭头不要穿过任何一个框实在绕不开就用连接点断开判断分支的是否文字要贴在箭头上方或右侧位置统一黑白打印时不能只靠颜色区分能用线型实线/虚线区分就用线型。还有一条很多人的通病框里的文字不要写自然语言长句。判断这个学生是否已经修满学分并且绩点达标这种描述应该拆成两个菱形或者简化成学分 要求 绩点 2.0让图保持可扫描性。8.3 从代码到图的抄作业流程最后给一个我自己用了很多年的固定流程照着做基本不会出大问题。第一步把代码的执行步骤按时间顺序编号写在纸上第二步把编号里所有的赋值动作圈出来它们对应处理框第三步把所有能回答真假的表达式圈出来它们对应菱形第四步把读取和打印圈出来它们对应平行四边形第五步按编号画箭头凡是编号出现回到第 X 步的地方就是回边的位置第六步对照前面的自检流程走一遍。这套流程的好处是它完全依赖代码本身的执行顺序不依赖你的记忆和直觉哪怕换成递归、异常处理这些更复杂的结构思路也是一样的。我个人在实际带新人和写文档的过程中最深的体会是循环流程图画得快不快和语法熟不熟关系不大和你脑子里有没有一条清晰的执行时间线关系极大。那些画得又快又准的人通常是在动手画图之前已经在脑中把循环跑过一遍了。另外分享一个小技巧如果你手头的图比较复杂可以先用铅笔在纸上把变量值一格一格地列出来看着数字怎么变再决定框怎么摆比直接对着代码描线要可靠得多也更容易发现那些条件写反了步进漏了的隐藏问题。
带过几届新人之后我发现一个规律能一口气把 for、while、do while 的语法写得滚瓜烂熟的人不少但真让他把这三段代码各自画成一张规范的流程图十个人里有七个会在回边的落点上出错——要么把回边拉回起止框要么把i塞进菱形里要么判断框上长出三根箭头。循环流程图看起来是最基础的图实际上它同时考验三件事你对循环执行顺序的理解、你对流程图符号语义的掌握、以及你有没有在实际项目里被评审挑过毛病。这篇内容就是把这三种循环的流程图画法一次讲透从执行模型到符号约定从单层循环到嵌套和 break/continue配可直接照着画的案例适合正在学 C 语言、Python、Shell 语法的同学也适合需要画软件工程流程图、写毕业设计文档、做逻辑梳理的开发者。1. 先把三种循环的执行模型拆开看再谈流程图怎么落笔画图之前必须先想清楚一件事流程图不是语法的翻译而是执行顺序的翻译。你画的每一个框、每一根箭头都对应运行时真实发生的一步。所以如果对三种循环先做什么、后做什么、什么情况下回到哪里没有清晰的心智模型画出来的图必然是错的。我习惯在纸上先写出执行步骤的编号序列再把这些编号按顺序摆成图形这个方法能规避掉八成的结构性错误。1.1 for 循环的三段式结构决定了判断框的位置for循环的完整形态是for (初始化; 条件; 步进) { 循环体 }它的执行顺序是初始化只执行一次然后进入条件判断条件成立则执行循环体循环体执行完后执行步进步进结束后再次回到条件判断如此往复直到某一次判断不成立整个循环结束。这里最关键的一点是初始化在循环之外步进在循环体之后、判断之前。很多人画图时把初始化和步进都塞进循环体内图看起来能跑但语义完全变了——初始化会被重复执行循环变量的值每次都被重置逻辑上直接变成死循环。所以画 for 的流程图第一件事就是把初始化这个处理框放在菱形判断框的前面并且让回边指向菱形而不是初始化框。1.2 while 循环把判断提到最前面初始化和步进都要人工负责while (条件) { 循环体 }的执行顺序更简单先判断条件成立则执行循环体循环体执行完回到条件判断。它没有语法层面的初始化也没有语法层面的步进这两件事全部由写代码的人在循环外和循环体内自行安排。反映到流程图上就是初始化框画在循环外部通常是起止框之后的第一个处理框步进框画在循环体内部的最后一步回边从步进框指向菱形判断框。这个结构其实和 for 的流程图高度相似区别只在于 for 的步进是语法强制的while 的步进是人为约定的所以 while 的图更容易漏掉步进框——漏掉之后条件永远为真图就变成了一个没有出口的死循环。1.3 do while 把循环体压到判断之前回边的终点随之改变do { 循环体 } while (条件);最特殊它先无条件执行一次循环体执行完之后才去判断条件条件成立就回到循环体开头再执行一次不成立就往下走。这决定了两个画图上的硬性差异第一判断框出现在循环体之后而不是之前第二回边的箭头必须指向循环体的第一个框绝对不能指向起止框。指向起止框意味着整个程序重新开始包括初始化都会被重做那是完全不同的语义。我在评审新人图的时候do while 的回边指错位置几乎是最常见的问题十张图里能挑出五六张。1.4 判断位置带来的连锁差异用一张表说清三种循环的差异不是零散的它们都由判断框在哪这一个因素推导出来。把差异整理成表格画图时对着核对比凭印象画要稳得多。对比维度forwhiledo while判断框位置初始化之后、循环体之前循环体之前循环体之后循环体最少执行次数0 次0 次1 次初始化位置语法强制图的循环体外手动写在循环体外手动写在循环体外步进位置语法强制循环体执行完紧接着手动写在循环体内手动写在循环体内回边终点判断框菱形判断框菱形循环体第一个处理框适用场景次数已知的遍历与计数次数未知、先看条件再决定必须先执行一次再判断典型错误步进画进菱形漏掉步进框回边拉回起止框这张表里最值得多看一眼的是循环体最少执行次数这一行。0 次和 1 次看起来只差一次但在实际业务里差别巨大用 while 写读取用户输入并校验如果第一次输入就是合法的循环体一次都不执行那输入框根本就不会弹出来换成 do while用户至少会被要求输入一次这才是符合直觉的交互。很多线上 bug 的根源就是这里选错了循环类型。2. 流程图的符号约定哪些框能随便用哪些框一步都不能错符号用错图就是错的哪怕逻辑再正确也没法通过评审。国家标准的流程图符号体系里常用的其实就这么几种但每一种背后都有明确的语义边界混用会让读图的人产生错误预期。我见过有人用圆角矩形表示处理、用矩形表示起止图能看懂但放到正式文档里就是不规范的。这一章的规则不复杂但请务必钉死在脑子里因为后面所有案例都建立在这套约定之上。2.1 六种基本图形各自承担什么语义起止框圆角矩形或椭圆代表流程的开始和结束框内文字一般是开始结束或StartEnd。一张流程图有且只有一个主起止入口可以有多个结束出口比如异常分支、break 分支。处理框直角矩形代表一步计算或赋值比如sum sum i、i 1、i。所有改变数据状态的动作都放这里。判断框菱形代表一个能回答是/否的命题比如i 100、还有下一个元素。菱形里只能写条件表达式绝不能写赋值语句。输入输出框平行四边形代表与外部交换数据比如输入 n、输出 sum、读取一行。虽然写进处理框程序也能跑但在文档里区分开更专业。连接点小圆圈用于跨页或跨区域连接流程线嵌套循环里尤其有用。流程线带箭头的实线表示执行方向。回边、分支边都靠它表达。把这六种框和它们的用法列清楚之后你会发现流程图其实是一门约束性语言——它的表达能力有限正是这种有限性让逻辑无处藏身任何含糊都会暴露成图形上的不规范。2.2 判断框的两条铁律判断框是整个循环流程图里信息密度最高的地方它有两条不能破的规矩。第一条一个菱形只有一个入口、两个出口出口分别标注是和否或 Y/N、True/False。如果你发现一个菱形需要三个出口说明这个判断应该拆成两层或者后面接了 switch 类的多分支结构。第二条菱形里写的内容必须是命题必须能被判定真假不能出现i、sum i这类动作描述。我见过最典型的错误是把 for 的整个头部i 1; i 100; i抄进一个菱形这种图读起来毫无意义因为读者无法判断是和否分别走哪条路。2.3 回边才是循环流程图的灵魂普通顺序结构的流程图箭头一路向下就完事了一旦出现循环图里就会多出一种向上走的边这就是回边。回边画得好不好直接决定图能否被正确理解。三条经验回边一律从循环体的最后一步出发for 是从步进框出发while 是从循环体末尾的处理框出发do while 是从判断框的是分支出发回边必须与向下的主干线在视觉上区分开通常走图的左侧或右侧竖直通道不要贴着中间的框回边的终点必须是判断点do while 除外它指向循环体首框指向别处都会改变语义。实际画图时我习惯把所有回边统一靠右走这样一张图里向上走的线一眼就能数出来嵌套层数也就一目了然。3. for 循环流程图初始化与步进该放在循环外面还是里面这一章用真实的代码案例把 for 的流程图一步步搭出来。之所以从一个最朴素的累加案例开始是因为它包含了 for 循环的全部结构性要素初始化、判断、循环体、步进、回边一个都不少。把这一个画对了后面无论是遍历数组、处理字符串还是嵌套循环都只是在骨架上加东西。3.1 C 语言经典 for 到图形的映射过程先看代码这是求 1 到 100 的和int sum 0; for (int i 1; i 100; i) { sum i; } printf(%d, sum);按执行顺序拆解得到七个步骤sum 0i 1判断i 100成立则sum sum ii回到判断不成立则输出sum并结束。把这七步翻译成图形节点顺序如下表顺序图形框内文字出边指向1起止框开始节点 22处理框sum 0节点 33处理框i 1节点 44菱形i 100 ?是到节点 5否到节点 75处理框sum sum i节点 66处理框i i 1回节点 47输入输出框输出 sum节点 88起止框结束无这里有两个位置必须反复确认节点 3 的i 1在菱形之外节点 6 的i i 1在循环体内但在回边之前。如果哪天你画的图里i 1出现在节点 5 和节点 6 之间那这张图的逻辑就是错的因为每次循环都会把 i 重置成 1条件永远成立。3.2 Python 的 for 其实是迭代器循环图要跟着变形Python 里写for i in range(1, 101)语法上看着像 C 的 for但底层机制完全不同它是在遍历一个可迭代对象没有显式的初始化变量和自增操作。所以硬套 C 的模板去画 Python 的 for 流程图会画出一个看不见的 i图里凭空多出一堆没写过的框。正确做法是把判断框写成还有下一个元素循环体首步是取出当前元素赋给 itotal 0 for i in range(1, 101): total i print(total)对应的图形顺序是起止 →total 0→ 菱形迭代器中还有元素→ 是取出元素i 当前元素→total total i→ 回菱形 → 否输出 total → 结束。注意回边依然指向菱形因为 Python 的 for 本质上就是先判断有没有下一个再取出来处理和 while 的结构是同构的。这一点想通了你看 Python 的 for 和 while 就不会再有割裂感。3.3 Shell 与增强 for 的画法差异Shell 脚本里的循环写起来很不一样sum0 for i in $(seq 1 100); do sum$((sum i)) done echo $sum它同样是遍历式的$(seq 1 100)会先生成一个序列然后 for 依次取出每个值赋给 i。画图时判断框写序列中还有未取出的值循环体内先取下一个值赋给 i再累加。Java、C# 的增强 for 循环、C 的 range-based for 也是这个套路判断框统一写成还有下一个元素不要写成i 100因为你在图里根本没有暴露 i 的增长过程写条件表达式反而会自相矛盾。另外 Shell 是一种命令式文本环境输入输出框在它的流程图里用得比其他语言多读文件、打印结果、执行命令都适合画成平行四边形这样图的层次会更清楚。4. while 循环流程图判断前置结构下最容易漏掉的两根线while 是三种循环里最诚实的一种——你写什么它执行什么没有任何语法糖帮你兜底。好处是省心坏处是所有责任都落到写代码的人身上。画 while 的流程图时只要记住初始化在圈外、步进在圈内、回边指菱形这三句话基本不会错。但每年总有大量的人栽在同一个地方循环体里忘了写让条件趋向结束的那一步。4.1 从 while 累加案例拆一遍完整画法同样求 1 到 100 的和用 while 改写int i 1, sum 0; while (i 100) { sum i; i; }拆成步骤是i 1sum 0判断i 100成立则sum ii回判断不成立则输出。图形节点顺序为起止 →i 1→sum 0→ 菱形i 100 ?→ 是sum sum i→i i 1→ 回菱形 → 否输出 sum → 结束。和 for 的图放在一起对比你会发现while 的图只差两点初始化两个框的位置由语法决定变成了人为摆放步进框从语法保证存在变成了全靠自己记得写。我通常建议初学者把 for 和 while 的图并排画在同一个本子上差异一眼可见比背十遍笔记都管用。4.2 边界条件在菱形里到底该怎么写菱形的写法直接决定循环执行多少次这是最容易被忽略的细节。i 100执行 100 次i 100执行 99 次。别小看这一次的差别我在实际项目里见过因为边界写错导致分页少查一条记录、日志漏掉最后一行、数组越界一个元素的真实故障。画图时的习惯做法是在菱形旁边用铅笔标注一行小字写明这个条件成立时的取值范围和循环执行次数比如i 取 1 到 100共 100 次。正式文档里不好加批注那就画完之后自己按图跑一遍脑中推演把初始值代进去确认第一次能不能进循环再把终止前的值代进去确认最后一次能不能进。4.3 死循环与 while(1) 的标注方式有些循环本来就是要一直转下去的比如服务主循环、单片机扫描循环、命令行程序的事件循环。这时候条件恒为真while (1)或while (true)流程图里会画出一个永远走是分支的菱形。这种情况下不要傻乎乎地画一个没有否出口的菱形规范做法是保留两个出口把否分支连到一个真正的结束框或者直接不画线同时在菱形旁边加一个注释框写明由内部 break 或外部信号终止。如果循环体内有if (...) break;那就必须把 break 的箭头明确画出来指向循环之后的第一个框。图里只要出现了恒真菱形就一定要有明确的退出路径否则读图的人会认为这张图有 bug。5. do while 循环流程图回边为什么必须指向循环体第一框do while 是三种循环里画错率最高的一种原因很直接——它的图形结构和另外两种不太一样判断框跑到了后面回边的方向也变了。很多人画图时是肌肉记忆式地把回边拉回菱形结果画出来是 while 的图只是框的顺序被调换了逻辑上完全说不通。5.1 至少执行一次这个特性怎么落到图上看代码int score; do { printf(请输入成绩(0-100): ); scanf(%d, score); } while (score 0 || score 100);执行顺序是先显示提示语再读取输入然后判断成绩是否越界越界就回到显示提示语这一步重新来合法就继续往下。翻译成图形起止 → 输出请输入成绩 → 输入 score → 菱形score 0 || score 100 ?→ 是回边指向输出请输入成绩框 → 否往下走。请特别注意回边箭头的落点——它落在循环体的第一个处理框上而不是起止框。如果落在起止框意味着整个程序重启初始化、资源申请全部重做这在语义上完全是另一回事。5.2 输入校验与菜单驱动两个高频场景do while 的典型应用场景有两类。第一类是输入校验就是上面那个例子你必须先让用户输入一次才能判断他输得对不对先判断再输入在物理上就说不通。第二类是菜单驱动比如控制台程序显示1. 查成绩 2. 改密码 0. 退出用户选 0 才结束。它的流程图结构是起止 → 输出菜单 → 输入选项 → 判断选项是否为 0 → 是结束否执行对应功能 → 回到输出菜单。这里回边同样指向第一个处理框。这两类场景有共同特征动作必须发生一次以上才有意义且动作本身是判断条件的数据来源。只要满足这个特征就应该优先考虑 do while而不是硬用 while 加一个先行的重复代码块去凑。5.3 break 与 continue 在 do while 里的落点这两个语句在三种循环里的含义一致但在 do while 的图里落点有讲究。break的箭头应该直接指向循环结束后的下一个框跨越整个回边不要画成回到判断框。continue在 do while 里的语义是立刻跳到条件判断而不是跳到循环体开头所以箭头应该指向菱形判断框。很多资料画 continue 时统一画成回边这是不对的——在 while 和 for 里continue 的落点分别是判断框和步进框在 do while 里是条件判断三者都需要区分。如果一张图里同时出现 break 和 continue建议用不同线型或在线旁标注文字避免读者分不清哪根是哪根。6. 同一道题三种画法把差异摆在一起看才记得住光看单张图永远记不牢真正让人形成肌肉记忆的方法是同一个需求用三种循环各画一遍然后把三张图摆在一起对照。差异会自己跳出来不需要你额外背。这一章挑两个最具代表性的题目把三种画法的核心节点列出来。6.1 求和题的三种图形骨架对照需求是求 1 到 n 的和n 由用户输入。三种循环的图形骨架对照如下环节for 画法while 画法do while 画法输入 n起止后首个平行四边形同左同左初始化变量处理框 i1, sum0处理框 i1, sum0处理框 i1, sum0判断框位置初始化框之后初始化框之后循环体累加之后循环体内容sumsumisumsumisumsumi随后 ii1步进位置循环体之后、回边之前循环体末尾循环体末尾回边终点判断框判断框循环体首框从这张表能看出一个很重要的规律当循环至少需要执行一次时do while 的图会比其他两种更紧凑因为它把判断挪到后面去了。但如果循环次数可能为 0比如 n 为 0 时不求和do while 就错了它至少会加一次结果就多加了 1。这种0 次 vs 1 次的判断才是选循环类型时最该花时间想清楚的问题比纠结画法本身重要得多。6.2 菜单驱动的三种写法对比以显示菜单 — 选择功能 — 执行 — 回到菜单为例。用 while 写需要把显示菜单写两遍一遍在 while 之前一遍在循环体末尾流程图里就会出现两个内容完全相同的平行四边形看起来重复且容易改漏一处。用 do while 写只需要一个显示菜单框图干净很多。用 for 写则更别扭你很难在语法上表达用户不选退出就一直循环这件事通常只能写成for (;;)配上内部的 break这时候图里会出现一个恒真菱形加一根 break 箭头反倒比 do while 复杂。结论很明确这种先做再判断的场景do while 的图结构最简、最不容易出错评审时也最容易让人一眼看懂意图。6.3 把两张图并排贴在文档里的技巧如果你在写毕业设计或技术文档需要同时展示三种循环的差异建议按for 左、while 中、do while 右横排三张图使用完全一致的框尺寸、字号和颜色只在关键差异处判断框位置、回边终点用加粗边框或深浅不同的填充色区分。三张图对齐之后读者扫一眼就能看出差异所在比写一大段文字解释有效得多。如果版面限制只能竖排那就把三张图的判断框用同一条水平虚线贯穿对齐视觉上依然能形成对照关系。7. 循环流程图常见的九种画错方式与排查顺序画错了不可怕可怕的是不知道错在哪。这一章把我在代码评审和文档评审中反复见到的问题归成三类并且给出一套按顺序执行的排查方法。你可以把它当成一份自检清单每次画完循环流程图之后照着过一遍两分钟就能筛掉大部分低级错误。7.1 结构类错误回边、初始化、步进回边指向起止框这是头号错误会让初始化被重复执行初始化画进循环体内同上步进框缺失或位置不对在 for 里表现为步进跑到回边之后那样永远执行不到在 while 里表现为压根没画直接变成死循环循环体的第一个框被回边越过在 do while 里表现为回边指到了第二个框。这四类错误的共同点是可以纯靠结构检查发现不需要理解业务逻辑。我的检查方法是用手指顺着箭头走两遍第一遍走条件成立的路径看能不能回到该回的地方第二遍走条件不成立的路径看能不能正常走出去。7.2 语义类错误条件表达式与循环变量菱形里写了赋值语句比如i i 1这属于图形语义错误判断条件和实际代码不一致写代码是i n画图写成i n循环变量在循环体内被意外修改但图中未体现比如循环体里有个i i 2画图时只画了i图上和代码就对不上了累加变量忘记初始化就参与运算代码里有隐患图上也没体现初始化框评审时会被直接打回来。这类错误需要拿代码和图逐行对照建议在画完图之后反向把图读成伪代码再和原代码比对效率比正向核对高。7.3 嵌套循环与 break/continue 的处理方式嵌套循环的图不要画成一堆交叉的箭头那样谁也看不懂。规范做法是内层循环先用一个处理框占位在单独的一张子图里画内层循环的细节主图里通过连接点或子流程框引用它或者用内外两条不同侧的回边通道外层走最右侧内层走内侧视觉上分层。break 和 continue 的处理前面说过关键是落点break指向循环之后的框continue在 for 里指步进框、在 while 里指判断框、在 do while 里指判断框。嵌套场景下break 只跳出最内层所以箭头只能跨过最内层的回边千万不能画成一下子跳到最外层之后那是 return 或带标签的跳出。7.4 一套两分钟自检流程画完图后按这个顺序走第一步看起止框确认只有一个人口第二步找所有菱形逐个确认只有两个出口且框内是命题第三步顺箭头走一遍成立路径确认回边落点正确第四步走一遍不成立路径确认能到结束框第五步把图翻译成伪代码和原代码对照第六步检查所有处理框里的变量是否都在使用前被初始化过。这六步做完一张规范的循环流程图基本就成型了。我个人的习惯是把这六步写在便利贴上贴在显示器边上画完一批图之后统一过一次比画一张查一张要快。8. 绘图工具与排版细节让图能直接贴进文档图画对了只是及格能不能直接贴进技术文档、能不能黑白打印、能不能让同事一眼看懂是另一层功夫。这部分看起来是美化实际上影响着图的可用性尤其在需要提交评审或者写论文的场合规范的排版能省掉大量来回修改的时间。8.1 工具选择要按场景来定不同的绘图工具适合不同的场合。在线协作类工具如 ProcessOn、draw.io 网页版适合团队一起看、一起改拖拽顺手模板多缺点是复杂图容易卡桌面类工具如 Visio、draw.io 桌面版适合画大型、多页的图文件本地保存排版精度高适合正式交付Office 内置形状适合已经用 Word 写文档、图不多的情况好处是不用切换软件、粘贴后仍然可编辑缺点是画复杂图会很累纸笔加拍照适合想逻辑的阶段我到现在还保留着先手绘草图再用工具重画的习惯草图上改十遍的成本比软件里改一遍低得多。另外提醒一句很多工具提供代码转流程图的功能自动生成的图逻辑通常是对的但框的位置、线的走向往往很乱还需要手工调整别指望一键出成品。8.2 排版上必须遵守的几条硬规矩同层级的框必须同一尺寸、同一字号不要出现一个菱形大一个菱形小的情况同一水平线上的框必须严格对齐差几个像素在打印稿上非常刺眼回边统一走一条侧向通道不要一根在左一根在右箭头不要穿过任何一个框实在绕不开就用连接点断开判断分支的是否文字要贴在箭头上方或右侧位置统一黑白打印时不能只靠颜色区分能用线型实线/虚线区分就用线型。还有一条很多人的通病框里的文字不要写自然语言长句。判断这个学生是否已经修满学分并且绩点达标这种描述应该拆成两个菱形或者简化成学分 要求 绩点 2.0让图保持可扫描性。8.3 从代码到图的抄作业流程最后给一个我自己用了很多年的固定流程照着做基本不会出大问题。第一步把代码的执行步骤按时间顺序编号写在纸上第二步把编号里所有的赋值动作圈出来它们对应处理框第三步把所有能回答真假的表达式圈出来它们对应菱形第四步把读取和打印圈出来它们对应平行四边形第五步按编号画箭头凡是编号出现回到第 X 步的地方就是回边的位置第六步对照前面的自检流程走一遍。这套流程的好处是它完全依赖代码本身的执行顺序不依赖你的记忆和直觉哪怕换成递归、异常处理这些更复杂的结构思路也是一样的。我个人在实际带新人和写文档的过程中最深的体会是循环流程图画得快不快和语法熟不熟关系不大和你脑子里有没有一条清晰的执行时间线关系极大。那些画得又快又准的人通常是在动手画图之前已经在脑中把循环跑过一遍了。另外分享一个小技巧如果你手头的图比较复杂可以先用铅笔在纸上把变量值一格一格地列出来看着数字怎么变再决定框怎么摆比直接对着代码描线要可靠得多也更容易发现那些条件写反了步进漏了的隐藏问题。
![GO [ 泛型 ]](http://pic.xiahunao.cn/yaotu/GO [ 泛型 ])
