企业官网建设流程全解析

1. while 循环到底卡在哪儿：先把定位想明白

很多人学编程学到 while 循环这一节，会有一种奇怪的错觉——语法看一遍就懂了，while (条件) { 循环体 }，三个词，五分钟能背下来，然后做题的时候照样写出一堆跑不完的死循环，或者循环跑完了结果差了那么一两个数。我见过太多这种情况，问题的根源几乎从不在语法本身，而在于没有建立起"循环是一个需要被管理的过程"这个意识。while 循环这门东西，本质上不是让你学一个关键字怎么敲，而是让你学会用"不知道要转多少圈"的方式去描述一件事——这是编程思维里第一次真正意义上跟"不确定次数"打交道。

这篇文章我想把它当成一个完整的小专题来写，不是照本宣科地讲语法，而是把 while 循环从"为什么需要它"、"一次轮次里发生了什么"、"怎么写才不出事"、"出事了怎么查"这几层拆开。适合两类人看：一类是刚学完 if 判断、正准备上手循环的新手，另一类是用了很久 while 但每次调试都在打补丁、想弄清楚自己到底在补什么的老手。前者能拿到可直接抄的模板和判断标准，后者能拿到排查路径和那些文档里不会写的坑。文中所有代码都是能直接在本地跑起来的最小例子，你完全可以边看边敲。

1.1 一个"次数未知"的循环需求

理解 while 最好的入口，是先想清楚 for 循环搞不定什么。for 的思维方式是"我要做 N 次"，N 在开始之前就已经知道或者至少能算出来：遍历一个长度固定的列表、打印九九乘法表、跑 100 次压测。这类任务的共同点是次数封闭，你心里有底。但现实里大量任务不是这个形状的。

举个特别常见的例子：让用户输入一个合法的手机号，输入不对就重新输。你事先知道用户会输错几次吗？不知道。可能第一次就对，可能连错五次，理论上还可能一直错下去。这时候你没法写"循环 3 次"，因为可能是 2 次，也可能是 7 次。你能描述的只有一件事——"只要还不合法，就继续要输入"。这句话翻译成代码，就是 while 的形状。

再比如：从一个数开始反复除以 2 直到它小于 1，问除了几次；从链表头开始顺着指针往下走直到走不动；从一个文本里不断读下一行直到文件结束。这三件事的共同结构是"终止条件取决于运行过程中的状态，而不是事先给定的次数"。凡是这种形状的需求，while 都是天然的第一选择。这也是为什么在实际工程代码里，while 出现的频率并不比 for 低——业务逻辑里"一直做到某个条件成立"的场景，比"精确做 N 次"要多得多。

所以我常跟人说，while 不是 for 的简化版，也不是 for 的替代品，它解决的是另一类问题。你把这两者的定位搞混，就会陷入两种典型的错误：用 for 去硬凑一个次数不确定的循环，写出一堆for (int i = 0; ; i++)加break的怪东西；或者用 while 去写一个明明次数已知的遍历，然后在里面手动维护下标，多了一堆出错的机会。

1.2 while 与 for 的分工边界

我在实际写代码时用的判断标准很粗暴，但很好用：如果我能用一句话说清楚"什么时候停"，并且这句话里不包含具体的次数，就用 while；如果我说的是"做 N 次"或者"遍历这堆东西"，就用 for。

这张表不是死规矩。有些语言里 for 的写法极其灵活，能表达 while 的一切；有些场景两者完全等价，选哪个纯看可读性。但它能帮你在动手之前先把思路定下来，避免写着写着结构就歪了。我个人的习惯是：先想清楚这个循环的"终止条件"长什么样，如果它是一个布尔表达式而不是一个计数比较，那我就毫不犹豫用 while；如果它就是一个计数比较，那我宁愿用 for，因为 for 把初始化、条件、更新三个动作挤在一行，视觉上更难漏掉。

还有一个常被忽略的点：while 的写法在语义上更强调"条件"，而条件是可以随时被循环体内部改变的。这意味着 while 天然适合写那种"循环体执行完才发现该不该继续"的逻辑，比如处理一个队列直到队列为空——你在开始前并不知道队列里有多少元素，每处理一个就少一个，判断"队列还非空吗"就是最自然的终止条件。换成 for 你反而要先取一次长度，还得考虑循环过程中队列长度会不会变，反而更绕。

2. 拆开看：while 一次完整轮次里发生了什么

语法上的while (条件) { 循环体 }只有三个组成部分，但它每一次"轮次"实际执行的顺序是固定的四步：判断条件、条件为真则执行循环体、循环体执行完回到条件处、条件为假则跳出。这四步听起来像废话，但我可以负责任地说，绝大部分死循环和差一错误，都是因为写代码的人脑子里对"这四步谁先谁后"的印象是模糊的。

举个最典型的例子：循环体里那句更新循环变量的语句，到底应该放在循环体的开头、中间还是结尾？放在开头，可能第一轮还没处理数据就先把状态改了；放在结尾，如果中间有个continue跳过了它，就死循环了；放在中间的某个分支里，那其他分支就漏更新了。这些问题在语法层面看不出来，只有把执行顺序在脑子里跑一遍才能发现。

2.1 条件判断的位置决定了整个语义

while 的条件判断发生在循环体之前，这叫做"先判断后执行"，也常被称作"当型循环"。这个设计带来的直接后果是：循环体可能一次都不执行。如果一开始条件就是假，那 while 里面的代码一行都不会跑。这一点非常关键，因为它决定了 while 之后的状态是否还能被信任。

我踩过一个很实在的坑：写了一段从某个数开始一直减到 0 的循环，循环体里往一个累加变量里加东西，然后循环结束后直接用这个累加变量。结果输入恰好是 0 的时候，循环体一次都没进，累加变量还是初始值，后面算出来的结果就是错的。这类问题排查起来特别费劲，因为大部分测试用例都是正数，只有边界值才会暴露。

对比一下 do-while，它的顺序是"先执行一次，再判断"，所以循环体至少会跑一遍。这两种结构的差别不是风格问题，而是语义问题。什么时候必须用后判断？就是那种"至少得先做一次，做完才知道要不要继续"的场景，比如显示菜单让用户选，选完才知道是否退出；比如先尝试发一次请求，失败了才决定是否重试。这种场景你用 while 硬写，就得在循环前面把同样的代码再抄一遍，抄出来两处逻辑，改的时候很容易只改一处，留下一个隐藏 bug。

条件判断还有一个细节值得说：条件表达式的求值是有副作用的。比如while (scanf("%d", &x) == 1)这种写法，把读取动作塞进了条件里，每判断一次就相当于读一次数据。这种风格老手用得很爽，因为它把"读数据"和"判断读到没有"合并成了一步，代码极其紧凑。但对新手来说这是个陷阱，因为条件的执行次数是"循环次数 + 1"——最后一次判断失败，但那次读取动作已经发生了。如果你后面还要用这个变量，就会拿到一个"多读进来的"值。我的建议是：新手阶段老老实实把读取写在循环体里，等你能一眼看出条件的副作用时再用紧凑写法。

2.2 循环变量的三个动作缺一不可

我教别人写 while，永远是先让他们背三个动作：初始化、判断、更新。这三个动作必须都出现，少一个就出事。

初始化决定了循环从哪里开始。少了它，循环变量可能是一个未定义的垃圾值，在某些语言里直接给你随机数，跑出来的结果完全不可复现；在另一些语言里编译都过不去，反而是好事。更隐蔽的情况是变量在外层作用域已经被赋过值，你在循环里忘了重置，第二次进这段代码时用的就是上一轮的残留值。这种 bug 在函数被反复调用时才会露头，非常折磨人。

判断就是 while 后面那个表达式，它得能真实反映"该不该继续"。这里最常见的错误是用错了比较符，<=写成<，结果少处理最后一个；或者用!=去判断一个可能跳过目标值的变化过程，比如每次加 2 却要和 5 比较，那永远等不到相等，直接死循环。我的经验是：能用<或<=就别用!=，除非你非常确信那个变量的变化步长能精确命中目标值。

更新是最容易被忘掉的那个。忘更新就是死循环的头号成因，没有之一。更麻烦的是"更新了但更新错了"：本来该减的写成了加，本该加 1 的写成了加 2 导致跳过了终止条件，本该在循环体末尾更新的被一个continue跳过去了。这几种情况在代码上看起来都很像，只有把每轮的变量值打出来才能发现。

提示：写完任何一个 while 循环，先不要运行，用眼睛在循环体里找到那句改变循环条件的语句。如果找不到，或者找到的那句在某些分支下不会被执行，那这个循环就有死循环风险。

2.3 用循环不变式给自己上保险

这个词听起来很学术，但实际用起来特别朴素。所谓循环不变式，就是"每一轮开始时都一定成立的那句话"。你写循环之前先在注释里把这句话写出来，然后检查三件事：进入循环前它成立吗？每轮结束后它还对吗？循环退出时它能帮你推出结论吗？

拿一个求和的循环举例：i从 1 开始，每次把i加进total，i加 1，条件是i <= n。这里的循环不变式是"total等于 1 到i-1的和"。检查一下：进循环前i=1，total=0，1 到 0 的和是 0，成立；每轮里把i加进去再让i自增，那新的total就等于 1 到新i-1的和，也成立；循环结束时i = n+1，代入不变式得到total是 1 到 n 的和，正好是要的结论。

这套检查方法的价值在于，它能提前暴露差一错误。你会发现很多"结果少 1"或"结果多 1"的 bug，用不变式一推就现形了：要么是初始值该设成 0 却设成了 1，要么是循环条件该用<=却用了<。我在写稍微复杂一点的循环时，都会在草稿上写这么一句话，几十秒的成本，能省掉半小时的调试。

3. 上手写：四个由浅入深的 while 实战

理论说再多不如动手。下面四个例子是我按难度排的，从最裸的计数开始，一直到嵌套和指针式遍历，每个都附上完整代码、执行过程分析和踩坑点。你可以直接复制到本地跑，也可以改几个参数看看行为怎么变——改参数这个动作特别重要，它是你验证"自己真的理解了"的最快方式。

3.1 计数与累加：最小可用模板

这是所有 while 的母版，其他写法都是它的变体。

n = 10 i = 1 # 初始化 total = 0 while i <= n: # 判断 total += i i += 1 # 更新 print(total) # 55

这段代码跑起来的每一轮我都可以背下来：i=1时判断 1<=10 为真，total变 1，i变 2；第二轮total变 3，i变 3……直到i=10时total加到 55，i变 11，再判断 11<=10 为假，跳出。总共判断了 11 次，执行了 10 次循环体。这个"判断次数 = 执行次数 + 1"的规律，在你之后分析任何 while 的开销时都用得上。

这里有个新手特别容易犯的错：把i += 1写在total += i前面。看起来只是顺序问题，结果会变成从 2 加到 11，总和一样但语义完全不同，而且如果n是边界值，比如n=0，前者一轮都不跑返回 0，后者会先加 1 再判断，返回 1。这类错误在没有单元测试的情况下极难发现，因为总和"看起来差不多"。

再提一个实际项目中很常见的变体：用 while 做"反复除以某个数直到不足"的计数。比如算一个整数能被 2 整除多少次：

def count_divisions(n, d): if n == 0: return 0 cnt = 0 while n % d == 0 and n > 0: n //= d cnt += 1 return cnt

注意这里的两个细节。第一，条件里加了n > 0，因为n变成 0 之后0 % d == 0恒为真，光靠取模判断会死循环——这是死循环里很典型的一种"数学上看着对，实际上边界炸了"。第二，取整除法用的是//而不是/，Python 里/会给你浮点数，浮点数参与取模判断会引入精度问题，4.0 % 2虽然等于 0，但再往下除就会变成 2.0、1.0、0.5，0.5 % 2 不等于 0 所以能停，但如果你除的是 3 或者其他数，就可能出现2.9999999这种判断不出来的情况。整数运算和浮点运算在循环里混用，是后面第 4 节要专门讲的一个坑。

3.2 二分逼近：次数由计算推出的循环

这个例子值得单独拿出来，因为它是"用 while 表达一个次数事先可以算、但没人愿意算"的循环。典型场景是在一个有序范围内找一个满足条件的值，每次把范围砍一半。

def find_threshold(limit): lo, hi = 0, limit while lo < hi: mid = (lo + hi) // 2 if mid * mid < limit: lo = mid + 1 else: hi = mid return lo

这段代码找的是最小的那个整数，它的平方不小于limit。循环条件写lo < hi而不是lo <= hi，这个差别直接决定了会不会死循环：如果写lo <= hi，当lo == hi时还会再进一轮，此时如果分支没把lo或hi挪动，下一轮条件依然成立，就卡死了。这类"两个指针互相逼近"的循环，判断条件里用<还是<=，是无数人卡过的地方。

为什么这种循环用 while 而不用 for？因为循环次数是log2(limit)次，大概 20 次左右（假设 limit 是百万级），你当然可以算出这个次数然后用 for 跑，但那样代码会变成"我跑了 20 次，剩下的交给运气"，一旦范围或步长变了，次数就不对了。用 while 表达"只要范围还没收缩成一个点就继续"，语义是自洽的，范围多大都能跑对。

我在实际项目里用过这种写法的变体：处理一个不断缩小的批次，每轮把待处理集合砍掉一半，直到剩余量小于一个阈值。这时候条件写成while len(pending) > BATCH_MIN，每次从pending里取走一半。这个写法比 for 清晰得多，因为它不关心要跑几轮，只关心"剩下的是否还值得继续"。

这里的心得是：二分类循环的调试，不要盯着结果看，要盯着lo和hi的变化看。在循环体里打一行print(lo, hi, mid)，跑三次就能看出范围是不是每轮都在收缩。如果某一轮打印出lo和hi没变，那下一轮必然一样，死循环就确认了。

3.3 输入校验：把"直到合法"写成循环

这是 while 最舒服的场景，也是最贴近真实业务的一种。核心形态是：先尝试一次，如果不合法就继续要，直到合法为止。

def read_age(): while True: raw = input("请输入年龄：") raw = raw.strip() if not raw.isdigit(): print("只能输入数字，请重试") continue age = int(raw) if age < 0 or age > 150: print("年龄超出合理范围，请重试") continue return age

这里用了while True加return跳出，这是实战中极其常见的一种写法，也叫"无限循环 + 出口"。刚学的时候老师可能会说"别写while True，容易死循环"，但真实项目里这个模式用得非常多，因为它的好处是把"什么时候结束"放在真正发生结束的地方——那里正好有全部上下文，判断自然，不用在循环头上重复写一遍条件。

用这种写法必须守住一条纪律：每一个分支最终都要么return、要么break、要么继续往下走到能改变状态的地方。上面代码里的两个continue都是回到循环开头重新读输入，这是安全的，因为input每次都会阻塞等待新的输入，状态一定会变。但如果你写的是while True里套一个纯计算的逻辑，两个分支互相continue又都不改变任何变量，那就是标准死循环。

还有个容易被忽略的现实问题：input()在真实环境里可能抛出异常（比如用户直接关了终端），在脚本里跑着跑着就崩了。生产代码里通常会包一层 try，或者给这个循环加一个最大重试次数的保护。这个保护不是不信任用户，而是防止程序在无人值守的情况下卡死——定时任务里跑一个等待输入的循环，那个任务就永远挂在那儿了，属于很严重的线上事故形态。

3.4 嵌套与指针式遍历：while 的另一半用法

while 的另一个重要用途是顺着结构往下走，比如链表、树、文件流。这类结构的共同点是"下一个在哪"要靠当前的节点告诉你，而不是靠下标算出来。

class Node: def __init__(self, val, nxt=None): self.val = val self.next = nxt def show(head): cur = head while cur is not None: print(cur.val) cur = cur.next

这段代码的形状值得记住：判断条件是"当前节点不是空"，更新动作是"走向下一个"。循环体里做的事情，就是"处理当前这个，然后把位置挪到下一个"。你把这个骨架换成文件读取、换成树的中序非递归遍历、换成状态机推进，结构是完全一样的。

指针式遍历最大的风险是环形结构。如果链表里不小心有个环，while cur is not None永远为真，程序会一直转下去直到内存或时间耗尽。生产环境里处理外部数据的场景（比如解析别人给的 JSON 结构），加一个步数上限是很实在的做法：

def show_safe(head, limit=10000): cur = head steps = 0 while cur is not None: print(cur.val) cur = cur.next steps += 1 if steps > limit: raise RuntimeError("遍历步数超出上限，疑似存在环") return steps

这个limit参数看起来有点土，但它救过我很多次。做法是把它设成一个明显大于正常规模的值（比如正常数据量是几千，上限设 10 万），一旦触发就说明数据结构本身有问题，而不是逻辑写错了。比起事后用性能分析工具去查"为什么这个函数不返回"，提前埋这个哨兵便宜得多。

嵌套 while 也顺手提一下。两层 while 的组合在处理二维数据时很自然，比如从一个矩阵的左上角往右下角走，遇到不满足条件就往回退一格。嵌套时最容易出的事是把内层的循环变量当成外层的用，或者内层的变量忘了在内层开头重置：

rows = 3 cols = 4 r = 0 while r < rows: c = 0 # 内层变量必须在内层开头重置 while c < cols: print(f"({r},{c})", end=" ") c += 1 print() r += 1

如果你把c = 0那行提到外层循环外面，第一行能正常打完，第二行开始c已经是 4，内层循环一次都不进，输出就只有一行。这个错误特别隐蔽，因为不报错、不死循环，只是"结果少了几行"，很容易被当成别的问题去查。

4. 死循环专题：九成 bug 都出在这几行

写 while 的人早晚会被死循环教训一次，区别只是教训得早还是晚、代价大不大。我在本地跑死循环最多就是风扇转一会儿，但如果这个循环在服务端跑，可能就是一次资源打满的事故。所以这一节我按"成因分类"来梳理，而不是按"症状"——症状都是转圈，但成因不同，治法完全不一样。

4.1 四类典型死循环及其成因

第一类最好查，把循环体看一遍就发现了。第二类最难查，因为代码"看起来更新了"，只是那条更新语句藏在某一条分支的后面。我踩过的一个真实例子是：一个批量处理的循环，里面判断某条数据异常就continue跳过，而指针推进的语句写在了异常判断之后，结果只要遇到一条异常数据，指针就不动了，程序卡死在那一条上。这种 bug 在数据干净的时候永远测不出来，一上真实数据就炸。

第三类属于思维上的疏忽，尤其是当变量的变化方向和你脑子里的"目标值"不在同一侧时。判断条件写i > 0意味着你要往下走，那更新必须是减；如果你写成了加，i会从 1 涨到 2、3、4，离 0 越来越远，条件永远为真。

第四类的隐蔽性在于它完全符合数学直觉。n % 2 == 0表示 n 是偶数，逻辑没错，但如果你在循环里不断把 n 除以 2，最终 n 会变成 0，而 0 是偶数，条件继续成立，接着 0/2 还是 0，就永远出不去了。类似的情况还有除以一个不断变小的数直到除不尽、从一个数里不断减去一个步长直到"减不动"，这些描述里都藏着"到了某个值之后状态不再变化"的陷阱。

4.2 浮点数与溢出：两个隐蔽的坑

浮点数这一块单独拎出来说，因为它骗过的人太多了。

x = 0.0 while x != 1.0: # 这个循环几乎必然死循环 x += 0.1

理论上加十次就到 1.0 了，但浮点数在计算机里是二进制近似表示的，0.1 存下来其实是 0.1000000000000000055511151231257827，十次加下来得到的是 0.9999999999999999，永远不等于 1.0。这个循环会一直加到x大到精度无法再体现 0.1 的增量为止，那时候x已经是个天文数字，程序早就卡死了。

正确的写法从来不是"等它等于"，而是"等它进入一个足够小的邻域"：

x = 0.0 eps = 1e-9 while abs(x - 1.0) > eps: x += 0.1

这个eps到底设多大是个经验活。粗略的标准是：比你能容忍的误差小一到两个数量级，同时不要小到被浮点精度本身吃掉（double 的有效位数大概 15 到 16 位十进制，eps设成1e-20就等于永远等不到）。工程上常用的做法是根据你的量的规模来定，比如判断一个长度是否到 0，1e-6就够了；判断一个概率，可能1e-12更合适。我在实际项目里倾向于把这个阈值提取成一个常量，别让它散落在各个循环里，否则改起来要找半天。

溢出是另一个隐蔽的坑，在 C 和 Java 这类有明确整数位宽的语言里尤其明显。最经典的写法是这个：

for (unsigned int i = n - 1; i >= 0; i--) { /* ... */ }

unsigned类型永远不小于 0，i >= 0恒为真，而且i减到 0 再减一次会回绕成最大值，循环直接变成无限。这个 bug 在编译器里的警告级别不一定提示，很多人是靠线上卡死才发现的。改法要么用有符号类型，要么把条件改成i-- > 0这种先比较后自减的写法，要么干脆把循环结构换成 while 加显式的判断。

还有一类"看起来不会溢出"的情况：循环变量的类型是int，每轮乘 2，跑到三十几轮就溢出了，溢出之后可能变成负数，条件判断直接变形。这种循环如果终止条件依赖于那个变量的大小，就会出各种诡异的路径。防护手段是提前算一下最大轮次，或者在循环里加点保护。

4.3 do-while 和 break/continue 的位置陷阱

break和continue本身不复杂，但它们在 while 里的位置会显著影响正确性。

continue的语义是"跳过本轮剩下的部分，直接回到条件判断处"。这句"跳过剩下的部分"就是杀伤力所在——如果你把循环变量的更新写在了continue之后，一旦走到那个分支，更新就被跳过了。修复办法只有两个：要么把更新挪到所有continue之前，要么改用do-while的思维，把更新放在循环体最后并确保所有分支都能走到。

我个人在团队里推的做法是：在 while 循环里如果要用continue，就把那个变量更新语句放在循环体的最顶部或者紧跟在条件判断之后，绝不允许它出现在任何可能被跳过的位置。这个约定看着有点土，但它把一类 bug 从"偶发"变成了"结构上不可能"，很值。

break相对安全，但有个嵌套的情况要注意：它只跳出最内层的一层循环。两层嵌套里内层break之后，外层还在继续跑。如果你的本意是整体退出，那得用一个标志变量，或者把逻辑抽成函数直接return。我见过一段代码用了三层嵌套加两个break，作者自己都没搞清楚最后一次break之后会从哪里继续，最后靠重写整个函数才解决。

至于 do-while，它的价值在于"至少执行一次"，但它的语法在不少语言里写得比较别扭（末尾要有分号），而且它的条件是在执行之后判断的，这就带来一个反直觉的点：do-while 的循环体里必须保证那个变量在第一次判断之前已经被赋过值，否则判断时用的是未初始化的值。另外在使用continue的时候，do-while 的行为和 while 不同——它会跳到末尾的条件判断处而不是循环开头，这个差异在跨语言迁移代码时特别容易出错，同一个continue在两种结构里走的路不一样。

5. 排错与验证：把 while 写稳的工程习惯

前面讲了怎么写出正确的 while，这一节讲怎么验证它是对的、以及出错时怎么快速定位。说实话，这部分才是真正拉开差距的地方。会写 while 的人很多，能在五分钟内定位一个死循环的人不多。

5.1 排查速查表

遇到循环行为不对，我会按这个顺序过一遍，基本上一两分钟就能锁定范围。

这张表不是万能的，但它覆盖了我遇到过的绝大多数情况。值得强调的是"只在特定输入下出问题"这一行，因为大部分人调试时用的都是自己随手写的正常数据，正常的输入能跑通，边界值才会暴露问题。所以检验循环正确性的最低标准很简单：空输入、最小值、最大值，这三个必须试。空输入能测出"循环体一次都不进"的路径，最小值能测出初始值附近的方向问题，最大值能测出溢出和性能问题。

5.2 三个可复用的调试动作

第一个动作：在循环开头打一行带轮次和关键变量的日志。

i = 0 while i < n: print(f"[debug] round={i}, n={n}, flag={flag}") # ... i += 1

这行代码信息量比你想的大。如果打出来的是round=0,0,0一直不变，那就是漏更新。如果是round在涨但flag不动，那问题在更新的目标变量上。如果轮次涨到某个值就停了，那说明条件在那个点附近变成了假，去看看为什么。

第二个动作：给循环加一个轮次上限。

guard = 0 while condition(): # ... guard += 1 if guard > 100000: raise RuntimeError(f"循环轮次异常: state={state}")

这个保护上线前可以留着，上线后可以改成只记日志。它的价值不在"防止死循环"，而在于把"程序卡死、你去猜哪里卡了"变成"程序报错、错误信息里带着当时的完整状态"。一个带状态的报错，比一次无声的卡死值钱太多了。

第三个动作：在循环结束后立刻打印关键变量。

while i < n: i += 1 print(f"[debug] exit with i={i}, n={n}")

这一步专门用来抓差一错误。正常的循环退出时，i和n的关系是固定的（比如i应该等于n、n+1或n-1，取决于你的条件怎么写）。你把这行打出来，一眼就知道是循环提前退出了（i远小于n）还是根本没按预期推进。

5.3 多语言写法对照

最后把几种常见语言的 while 写法摆在一起，主要是为了处理"换个语言就写错"的问题。这些写法上的差异，往往就是坑的来源。

表里有一行值得单独说：JavaScript 里的隐式转换。while (x)在x是空字符串、0、null、undefined、NaN 的时候都会当假，这是很多人以为"写对了"其实没写对的地方。如果x恰好是 0，循环直接不执行，而作者可能认为 0 是个合法的值。稳妥的做法是永远显式比较：while (x !== null)、while (count > 0)，别依赖语言的转换规则。

至于 Go 那种没有 while 关键字的设计，其实挺让人清醒的——它提醒你 while 和 for 在语义上本来就是同一个东西，只是不同语言选择用不同关键字去承载。理解了这一点，你写循环时就不会再纠结"这里该用 while 还是 for"，而是先想清楚"这个循环的终止条件是什么形态"，形态决定写法，而不是关键字决定思路。

我自己的体会是，while 是那种越写越谨慎的结构。刚学会的时候觉得它万能，什么都能循环；写得多了反而会用得越来越少，能算清次数的就用 for，能抽成函数的就用迭代，只在真的需要"做到某个状态为止"的时候才掏出 while。这种收缩不是退步，恰恰是你开始对循环的代价和风险有感觉了——毕竟一个转不停的循环，代价从来不只是风扇声变大。