带过几届新人之后我发现一个规律：能一口气把 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 判断位置带来的连锁差异用一张表说清

三种循环的差异不是零散的，它们都由"判断框在哪"这一个因素推导出来。把差异整理成表格，画图时对着核对，比凭印象画要稳得多。

这张表里最值得多看一眼的是"循环体最少执行次数"这一行。0 次和 1 次看起来只差一次，但在实际业务里差别巨大：用 while 写"读取用户输入并校验"，如果第一次输入就是合法的，循环体一次都不执行，那输入框根本就不会弹出来；换成 do while，用户至少会被要求输入一次，这才是符合直觉的交互。很多线上 bug 的根源就是这里选错了循环类型。

2. 流程图的符号约定：哪些框能随便用，哪些框一步都不能错

符号用错，图就是错的，哪怕逻辑再正确也没法通过评审。国家标准的流程图符号体系里，常用的其实就这么几种，但每一种背后都有明确的语义边界，混用会让读图的人产生错误预期。我见过有人用圆角矩形表示处理、用矩形表示起止，图能看懂，但放到正式文档里就是不规范的。这一章的规则不复杂，但请务必钉死在脑子里，因为后面所有案例都建立在这套约定之上。

2.1 六种基本图形各自承担什么语义

• 起止框：圆角矩形或椭圆，代表流程的开始和结束，框内文字一般是"开始""结束"或"Start""End"。一张流程图有且只有一个主起止入口，可以有多个结束出口（比如异常分支、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 = 0；i = 1；判断i <= 100；成立则sum = sum + i；i++；回到判断；不成立则输出sum并结束。把这七步翻译成图形，节点顺序如下表：

这里有两个位置必须反复确认：节点 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++"，图里凭空多出一堆没写过的框。正确做法是把判断框写成"还有下一个元素？"，循环体首步是"取出当前元素赋给 i"：

total = 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 脚本里的循环写起来很不一样：

sum=0 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 = 1；sum = 0；判断i <= 100；成立则sum += i；i++；回判断；不成立则输出。图形节点顺序为：起止 →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 由用户输入。三种循环的图形骨架对照如下：

从这张表能看出一个很重要的规律：当循环至少需要执行一次时，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 步"的地方，就是回边的位置；第六步，对照前面的自检流程走一遍。这套流程的好处是它完全依赖代码本身的执行顺序，不依赖你的记忆和直觉，哪怕换成递归、异常处理这些更复杂的结构，思路也是一样的。

我个人在实际带新人和写文档的过程中，最深的体会是：循环流程图画得快不快，和语法熟不熟关系不大，和"你脑子里有没有一条清晰的执行时间线"关系极大。那些画得又快又准的人，通常是在动手画图之前，已经在脑中把循环跑过一遍了。另外分享一个小技巧，如果你手头的图比较复杂，可以先用铅笔在纸上把变量值一格一格地列出来，看着数字怎么变，再决定框怎么摆，比直接对着代码描线要可靠得多，也更容易发现那些"条件写反了""步进漏了"的隐藏问题。