1.1 Continue 的词义与在控制流中的定位
我第一次看到 continue 这个词的时候，脑子里蹦出来的其实是 Word 文档崩溃恢复时那个“是否继续”的弹窗。用在编程里，它的意思差不多就是字面意思——继续。不过编程里的这个“继续”，有一个很微妙的前提：它不是继续往下走，而是继续回到循环的开头。
我在学习控制流的时候，老师把三大结构画在黑板上：顺序、分支、循环。循环结构里面又拆出几个关键词，break 是打断，continue 是续上。break 像拔电源，continue 像按快进键跳到下一首。两者的“暴力程度”不一样——一个直接终止循环，一个只结束当前位置，然后回到循环的头部去判断条件。
有一个理解角度对我帮助特别大：把循环想象成一条传送带，每次循环是传送带上走过去的一个包裹。continue 就是你看到某个包裹标签不对，不去处理它，直接放它过去，然后伸手接下一个。你的手没停，你的工作流程也没变，只是对这个特定包裹少做了一步而已。
从语言设计的角度来说，continue 属于“跳转语句”这一族。同族的还有 break、return、goto。它在控制流图谱里画出来是一条向上回溯的箭头，指向循环体的起点。很多教材会把它和 break 放在一起讲，因为语法结构相似，都是单个关键字加一个分号或换行。但语义差得挺远。
1.2 Continue 语句的核心作用：跳过当前迭代，继续下一次循环
我刚学编程那会儿，特别喜欢用 if-else 把整个循环体包成一个巨大的树。写起来倒是挺符合直觉：条件满足做 A，不满足做 B。麻烦在于，一旦判断条件变多，缩进就会像梯田一样堆起来。
continue 做的事情就是把“不满足条件的那些情况”提前打发走。比如我在遍历一个用户列表，想跳过那些没有邮箱的用户。不写 continue 的话，我得把发送邮件的逻辑塞进 if user.email 里面。写了 continue 之后，判断和动作被拆开，代码的层次从“包进去”变成了“挡出来”。
这种思路有个名字叫“卫语句”（guard clause），continue 是它在循环里的具体表现。它的好处是每个迭代的主流程始终保持在一个缩进层级上，读取代码的时候不需要不断往右看缩进深度。人眼对于横向的追踪能力其实很弱，缩进越深，读起来越累。
从执行机制来看，continue 触发的那一刻，当前迭代里剩下的语句全部被跳过，程序控制权交还给循环结构本身——对于 while 循环，会重新判断循环条件；对于 for 循环，会先取下一个迭代元素，再判断循环是否结束。这个区别在调试的时候会体现出来，因为 while 里的 continue 如果不小心修改了计数器，很容易变成死循环。
我见过不少人把 continue 理解成“再次进入循环”，这个理解不太准确。它并不是从头开始执行循环体，而是结束本轮、进入下一轮。中间的差别在于循环变量是否已经被更新、迭代器是否已经往下走了一步。这个细节在处理列表和字典的时候影响很大。
1.3 为什么 Continue 值得单独学习：控制流、可读性与效率
有人会问，continue 就这么点东西，写篇文章值得吗？我一开始也这么想。后来看别人代码看多了，发现这个小关键字被误用、被忽略、被当成“语法糖”乱塞的情况特别多，才觉得它真的需要单独拿出来聊聊。
可读性上，continue 是一把双刃剑。用得好，代码像分层的过滤器，一层层把不符合条件的元素筛掉，剩下要处理的东西清晰可见。用得不好，散落在循环体各处的 continue 会让读者难以追踪究竟哪些情况会走到循环末尾，哪些会中途跳出去。我审代码的时候最怕看到的就是一个循环里有三四个 continue，而且每个的触发条件都写在很远的地方。
性能方面，continue 本身几乎没有额外开销，它只是一个跳转指令。它的“效率”更多体现在写法上——提前跳过不需要处理的数据，可以减少后面的函数调用、数据库查询、文件读写。我在处理日志的时候，经常用 continue 把空行、注释行先筛掉，再去解析有效内容。这样比全部读进来再过滤要省内存。
学习价值上，continue 是理解“控制流”这个概念的一个很好的入口。它强迫你去思考：程序执行到某一行的时候，下一步会跳到哪儿？这对后面学异常处理、生成器、协程都有帮助。我自己在学 Python 生成器的时候，突然意识到 yield 和 continue 其实都是对“控制权交还”的不同处理方式，一下子就通了。
总之，continue 不是一个孤立的语法点。它连着循环设计、代码结构、执行效率、可读性权衡这些话题。把它学透，循环这块就稳了一大半。我把这一章放在开头，也是因为我希望后面的内容都能围绕着“这个关键字究竟在控制流里扮演什么角色”来展开。
2.1 通用语法结构与伪代码表达
第一次把 continue 敲进编辑器的时候，我盯着屏幕愣了几秒，就这么一个词，没有参数、没有括号、甚至连分号都省了（看语言）。它是我学过的最短的语句之一。很难想象这么一个长得像占位符的东西，实际上在控制流里扮演着“重定向”的角色。
几乎所有语言的 continue 写法都差不多。C、C++、Java、JavaScript 结尾跟一个分号 continue;。Python、Ruby、Go、Swift 直接写 continue 换行。没有参数，没有表达式，它不携带任何数据，只携带一个动作意图——“本轮到此为止”。
伪代码可以帮助理解它的执行本质。把一个循环体想象成一段有编号的指令序列，continue 等价于 goto next_iteration。这个标签的含义随循环类型浮动。在 for 结构里它指向“取下一个元素并更新循环变量”的位置。在 while 结构里它指向“重新求值循环条件”的位置。同一句 continue，在两个不同循环里绕回去的落点不一样。这个认识对我来说很关键，因为后面所有关于 continue 的特殊行为，追到根上都是这个“落点差异”造成的。
还有一个所有语言共享的语法约束：continue 必须被循环结构包围。写在循环外面就是语法错误。Python 的报错是 SyntaxError: 'continue' not properly in loop。Java 给的是 continue outside of loop。我在 C 里试过把 continue 放进 if 块但忘了外面套循环，编译器直接罢工，提示信息比 Python 还简洁。各个语言的措辞不同，规矩是同一个——没有循环可以绕回去的时候，这个关键字无处安放。
2.2 在 for 与 while 循环中的执行流程
for 和 while 里 continue 的行为差异，是我调试时踩坑最多的地方，也是我认为每一个学 continue 的人都应该先搞清楚的事情。
for 循环的迭代推进由循环结构本身负责。我写 for item in items:，每轮开始前解释器自动调用迭代器取下一个元素。continue 触发的时候，循环体后半部分被跳过，控制权回到迭代机制，取下一个元素这一动作照常发生。我不用操心循环变量会不会卡住，下一个元素该来还是会来，迭代器自己往前走。这个机制让 for 里的 continue 用起来相当放心，它就像一个只会向前拨动的传送带，你跳过某个包裹的处理，传送带不会因此停住。
while 循环完全是另一码事。推进动作由写代码的人手动负责，我没有 for 里那种自动兜底。continue 跳回条件判断的那一刻，读的是循环变量此时此刻的值，如果这个值在 continue 之前没被更新，条件就还是成立的，循环体再走一轮，continue 再触发，值依然没变，如此反复，程序卡死。我写过一个逐行读取日志的 while 循环，计数器在循环体末尾才自增，而某个分支里加了 continue 直接跳过了自增语句。程序跑起来之后风扇狂转，任务管理器一看 CPU 拉满，回头看代码才发现是计数器原地踏步。
我在 while 里用 continue 的时候会刻意把状态更新放到 continue 可能出现的位置之前。这个习惯有点丑，变量的自增和条件判断隔得老远。丑归丑，至少不会写出死循环。我甚至一度在 while 里尽量不用 continue，宁可多嵌套一层 if。后来接受了这个折衷方案：把更新语句提到循环体顶部，continue 再往哪儿跳都不会绕过它。
2.3 Continue 与循环条件、迭代器、循环变量的交互
continue 和迭代器之间的关系，是我有一次读 Python 源码注释的时候才算彻底明白的。
for 循环背后是迭代器协议在支撑。每轮循环开始时 Python 调用 iterable.__next__() 拿一个元素，拿到元素之后才进入循环体。continue 打断的是循环体内部的流程，它打断的位置在 __next__() 调用之后。这个顺序保证了下一次循环拿到的元素永远是列表里的后一个，不重复也不遗漏。我在调试器里单步跟踪过一个 for 循环，continue 执行之后程序指针跳回循环头部，紧接着执行的指令就是取下一个元素。这个观察让我彻底放下了对“continue 会不会重复处理同一个元素”的担心。
while 循环里没有这层自动保护。迭代推进靠的是循环变量自身的值变化，continue 回到条件判断时变量是什么值，下一轮就从什么状态开始。如果变量在 continue 之前没有变化，那就进入稳定状态，循环体反复执行同样的逻辑，产生同样的结果，条件永远为真。我碰到过一个更隐蔽的案例：变量确实变了，但变化的方式在 continue 前后不一致，导致循环虽然没有死锁，但会跳过某些应该处理的输入。排查这种 bug 比排查死循环难受，因为程序正常结束了，只是结果缺了几块。
循环变量的作用域也在交互范围内。Python 的循环变量在循环结束后仍然活在命名空间里，continue 不会影响这个生命周期。C 语言里 for (int i = 0; ...) 声明的 i 作用域限制在循环内，continue 之后仍然可见。Java 的增强 for 循环和传统 for 循环在变量可见性上也遵循各自的规则。这些细节平日写简单逻辑感受不到，一旦循环里套着函数调用、闭包、异步回调，搞清楚“continue 触发后哪个变量是什么值”就成了排查问题的切入点。
2.4 常见语言差异概览：Python、C/C++、Java、JavaScript 等
每个语言的 continue 都带着自己的个性，写多了之后会形成一种直觉，切换语言的时候能立刻感觉到不同。
Python 的 continue 写法最干净，不带分号，跟缩进规则配合。Python 还给循环配了 else 子句，循环自然结束（没有遇到 break）的时候执行 else 块。continue 不影响 else 的触发，因为它没有终止循环，只是跳过一轮。我第一次看到 for...else 的时候愣了半天，觉得这个设计反直觉，用了几次之后发现它在搜索场景里挺好用。
C 和 C++ 的 continue 在 switch 语句里有一个容易让人误判的行为。switch 内部的 continue 不会只跳出 switch，它会直接跳到外层循环的下一次迭代，整个 switch 剩余的 case 全部被绕过去。这个行为在很多代码规范里被标记为“容易引发 bug 的写法”。我写 C 的时候在 switch 里用过一次 continue，当时想跳过当前 case 的剩余逻辑继续循环，编译器没有报错，运行结果也对，但同事 review 的时候盯了那行代码很久，问我到底想干嘛。从那以后我在 switch 里改用 break 加标志变量，可读性反而上升了。
Java 的 continue 支持标签，continue outer; 可以直接跳到指定外层循环的下一次迭代。多重嵌套循环里想跳过内层、继续外层的时候，标签比标志变量简洁得多。Java 的 continue 在 for-each 里行为跟传统 for 一致，迭代器自动推进，不用手动管。
JavaScript 的 continue 也有标签形式，for...of 和 for...in 里按预期工作。forEach 回调里写 continue 直接报语法错，因为 continue 必须在循环结构里。想在 forEach 里跳过当前元素，只能写 return，效果上接近 continue，但它不能代替 break，因为没有“终止整个 forEach”这回事，只能靠抛出异常或者改用 for 循环。
Go 的 continue 在只有 for 一种循环结构的前提下，行为统一。配合标签能在嵌套里精准跳转。Ruby 的 continue 写作 next，Python 背景的人第一次看容易混淆，因为 Python 里的 next() 是取迭代器的下一个值，Ruby 的 next 才是跳过本轮。Swift 和 Rust 都支持 continue 加标签，语义一致。
这些差异背后有共同的骨架——跳过本轮，进入下一轮。每个语言在标签、作用域、异常处理、循环结构上的设计不同，导致同样的 continue 在细节行为上出现分叉。我遇到不熟悉的语言时，第一件事就是查它的 continue 在嵌套结构和条件判断里的具体行为，这个习惯帮我避开了不少跨语言的坑。
3.1 Python 中 Continue 的语法与缩进规则
Python 的 continue 是我在所有语言里见过的最“素”的控制流语句，没有括号、没有分号、没有参数，就是一个光秃秃的单词加一个换行。写起来轻，但它的缩进规则一点都不轻，因为 Python 靠缩进划分代码块，continue 放在哪个缩进层级，直接决定了它控制的范围是整个循环体还是某个 if 分支内部。
我刚开始写 Python 的时候吃过一次亏。循环体里先写了一个 if 判断，然后加了 continue，写完之后随手把 continue 的缩进调成了跟 if 同级。运行结果看起来“差不多对”，因为数据碰巧没暴露出问题。后来换了一批测试数据，输出少了一大截，我才回头发现 continue 的缩进位置比预期高了一层，它跳过的逻辑范围比我以为的大。Python 对缩进错误的容忍度很低，但 continue 这种语句的缩进错误很阴险，语法完全合法，只是语义变了。
continue 在 Python 里必须出现在循环体的代码块内部，不能写在模块顶层，不能写在函数里但循环之外，也不能写在推导式（comprehension）里。写在循环外会直接抛 SyntaxError: 'continue' not properly in loop。我在编辑器里试过把 continue 提到函数体的第一行，保存的瞬间 linter 就标红了，不用等到运行时才报错。
还有一点值得提前说清楚：Python 的 continue 只影响它所在的那一层循环，不会穿透到外层循环。嵌套循环里内层写了 continue，被跳过的只是内层的当前迭代，外层循环的迭代照常推进。Python 官方没给 continue 配标签语法，想在嵌套里精确跳到外层，得靠标志变量或者把内层逻辑抽成函数。
3.2 在 for 循环与 while 循环中的行为差异
for 循环里的 continue 用起来让人放心，因为迭代推进这件事 Python 替你做完了。for item in items: 这个结构背后是迭代器协议在工作，每轮循环开始的时候解释器调用 __next__() 拿下一个元素，continue 触发之后控制流回到循环头部，下一个元素的获取动作自动发生。我不需要管索引会不会卡住，不需要担心迭代器会不会停在原地。
while 循环里的情况完全不同。推进循环状态的责任在写代码的人身上。continue 跳回条件判断的那一刻，循环变量是什么值就是什么值。我可以给你看一个我实际写过的例子：一个用 while 写的数据清洗循环，循环变量是个游标，循环体中间有一段分支在遇到空值时 continue，而游标自增语句在那段分支之后。空值连续出现的时候，程序就在原地打转，游标不动，条件一直为真。那次我盯着终端里滚动的日志看了半分钟才意识到死循环了。
我现在在 while 里用 continue 有一个固定的写法习惯：把状态更新尽量往循环体靠前的位置放。这样不管后面哪里写了 continue，跳回去的时候状态已经变了。这个习惯会让代码的阅读顺序有点别扭，条件判断在最上面，状态更新紧接着，业务逻辑反而在后面。丑是丑了点，不会写出死循环。
还有一种 while True 加 continue 的写法我得提一下。这种结构下循环条件永远为真，退出循环完全依赖 break 或者 return。如果某个分支既没有 break 也没有更新状态，continue 就会造出一个永远不会结束的循环。我写网络爬虫的重试逻辑时用过这种结构，重试计数器忘在 continue 分支里没加，程序卡在失败重试上跑了一夜。
3.3 与 else 子句、try/finally、with 语句的交互
Python 的 for...else 和 while...else 是一个非常有特色但容易让人困惑的设计。else 块在循环自然结束的时候执行，也就是没有遇到 break 的时候。continue 不会触发 else 块，因为它没有终止循环，只是跳过了一轮迭代。我当初学这个语法的时候总忍不住把 else 想成“循环出错时才执行”，实际上它更像是“循环走完了都没找到目标”的兜底分支。
continue 跟 try/finally 的交互值得单独拿出来说。finally 块在循环体内部时，continue 触发的那一刻会先执行 finally 里的内容，然后再跳回循环头部。我在写文件处理的循环时利用过这个特性：每轮迭代打开一个文件，用 try/finally 保证文件句柄关闭，中间遇到不符合条件的记录就 continue，finally 依然会把文件关掉。这个组合让清理逻辑不必在每个 continue 分支里重复写。
with 语句跟 continue 配合也很自然。with open(...) as f: 包住的代码块里写 continue，上下文管理器会在控制流离开 with 块的时候执行清理动作。文件会被关闭，锁会被释放，连接会被归还。我用 continue 跳出 with 块的时候从来不担心资源泄漏，这个契约由 with 保证。这些都是 CPython 把清理逻辑绑定在控制流转移上的设计带来的好处。
3.4 在列表推导、生成器与异步循环中的限制与替代写法
列表推导式里的 continue 是个不存在的东西。我试过在推导式的 if 条件后面写 continue，Python 直接给语法错误。推导式的过滤逻辑靠的是 if 条件本身，条件不满足的元素会被自动丢弃，效果跟 continue 一样。写 [x for x in data if x > 0] 的时候，那些非正数元素相当于被“跳过”了，不需要显式的 continue。
生成器表达式也是同一套逻辑。我在需要惰性求值的场景里用生成器表达式替代带 continue 的循环，代码短了一截，内存占用也降了。(x * 2 for x in data if x % 2 == 0) 这行表达的意思，用传统 for 循环写就是遍历 data，遇到奇数就 continue，偶数就产出 x * 2。两种写法等价，前者更紧凑，后者在需要复杂逻辑的时候更清晰。
异步循环是另一个 continue 需要谨慎对待的场景。async for 结构里写 continue 的行为跟普通 for 一致，跳过当前迭代，下一个元素照常从异步迭代器里取出来。我写异步任务调度器的时候遇到过一个问题：在内层 continue 跳过的任务，外层的并发控制逻辑并不知道这个任务被跳过了，如果外层的计数或者状态更新依赖内层的处理结果，就会出现不一致。这种 bug 不容易复现，因为异步任务的完成顺序会变。我后来在异步循环里用 continue 都会格外留意状态更新是不是放在跳转点的前面。
3.5 Python 常见错误与最佳实践：避免无限循环、保持逻辑清晰
while 里的无限循环是 continue 相关错误里最常见的一种，也是后果最明显的。防住它的办法我自己总结了几条。状态更新尽量前置，这是最直接的一条。用 for 循环可以回避的问题就别用 while。如果必须用 while，在 continue 分支里写注释说明循环变量在哪里被更新，给自己的未来提个醒。
逻辑清晰方面，我踩过的最大的坑是过度嵌套。一个循环体里套了三层 if，每一层都有 continue，读代码的时候得在脑子里维护一个“当前处于哪个分支”的状态机。后来我改成把过滤逻辑提到循环开头，用一连串扁平的 if condition: continue 挡住不合格的情况，循环体的主体逻辑留在最后。这种写法一般叫“卫语句模式”，读起来像是从一堆脏数据里筛出干净的再处理，比多层嵌套好理解得多。
还有一条实践是别在 continue 的临界位置放副作用代码。比如某个变量的自增、某条日志的写入、某个状态的改变，放在 continue 前面还是后面会产生完全不同的结果。我改过一个 bug，日志里总是缺少被跳过元素的记录，原因就是那行日志写在了 continue 之后。把日志提到跳转点之前，问题解决。给 continue 留出足够清晰的边界，让读代码的人一眼看出“跳过的到底是什么”，这比任何技巧都管用。
4.1 控制流语义对比：跳过本次迭代 vs 终止整个循环
这两个关键字放在一起看，差别简单到可以用一句话说清：continue 是“这一轮我不玩了，下一轮我还在”，break 是“这局不玩了，我走了”。我在笔记本上给初学编程的朋友画过这两个概念的示意图，画的是一个环形跑道，continue 是跳过跑道上的某个障碍物继续跑，break 是直接从跑道出口走出去，后面还有多少圈都不跑了。
语义上的差异会体现在循环变量的状态上。continue 执行之后，循环变量的当前值保持不变，控制流回到循环头部重新判断条件，能进入下一轮就进入，不能进入就正常结束。break 执行之后，整个循环结构被拆掉，循环变量保留在当前值上停留在作用域里，代码从循环块的下一条语句继续走。我写数据处理脚本的时候经常靠这个区别来决定输出什么，用 continue 跳过异常记录，最后循环自然结束输出完整的处理报告；用 break 提前跳出，是想立刻拿到中间结果去做别的事。
for...else 这个结构把两个关键字的差别放得很大。else 子句只在循环自然结束时跑，也就是说 continue 不影响 else，break 会直接废掉 else。我在写查找逻辑的时候用得最多：遍历数据集找符合某个条件的元素，找到了 break 并把结果返回，找不到的话 else 块执行，打印一条“未命中”的提示。这两个关键字在 else 面前的分工非常清楚，一个负责过滤，一个负责终结。
4.2 执行路径可视化：Continue、Break、Return、Pass 的区别
我画过一张控制流对比图贴在显示器旁边，把 continue、break、return、pass 四个关键字标在同一条执行路径上，每个关键字画一个箭头指向不同的方向。continue 的箭头弯回去指向循环头部，break 的箭头直着穿过循环边界往后走，return 的箭头从函数里穿出去回到调用方，pass 没有箭头，就是一个原地不动的点。
pass 最容易被误认为跟其他三个是一类。它就是个占位符，Python 解析器看到它什么都不做，执行到 pass 的那一行代码只是“这里本来要写东西但现在先空着”。我在写框架代码的时候用 pass 占位，函数体、类体、异常捕获块里暂时不写逻辑就放一个 pass，语法能过。continue 和 break 是真的改变控制流走向，pass 是控制流走到这里需要有个语法节点但不需要任何动作。
return 跟 break 长得像，作用范围不一样。break 逃出的是循环结构，return 逃出的是整个函数。我调过一个 bug，一个函数里嵌套了两层循环，内层用 break 跳出内层之后，外层循环继续遍历剩下的数据，造成了大量重复计算。我把内层改成 return 直接返回结果，问题消失，函数执行时间降到原来的十分之一。两个关键字从某个角度看是可以互相替代的，取决于我想让控制流退到哪一层。
4.3 使用场景：过滤数据用 Continue，提前退出用 Break
数据过滤场景是我用 continue 最密集的地方。一批待处理的记录进来，每条记录都要经过几道校验：字段完整性、格式合法性、数值范围。所有这些校验都写成扁平的 if not valid: continue，不合格的记录在入口处就被挡住，循环体下半部分只处理确信干净的数据。我管这个模式叫“漏斗式过滤”，脏数据从上面进来，顺着漏斗壁滑走，干净数据从底下出去。这种结构的另一个好处是新增校验规则只需要在入口处加一条 if 加一个 continue，不用改动主体逻辑。
提前退出场景用的是 break。遍历一个大的数据集找某个特定元素，找到就可以停了，后面的元素没有看的必要。二分查找、线性搜索、状态机里碰到终止状态，这些都是 break 的典型使用场合。我写过一个日志分析工具，从文件头部开始扫，扫描到第一个错误标记就 break 并触发告警，不需要读完整份日志。文件可能有好几个 G，提前退出省下来的时间很可观。
两个关键字混用的场景也很多见。一个循环里前半段做过滤、后半段做终止判断，我写的批处理脚本里经常出现这种结构：遍历队列里的任务，遇到无效任务 continue，遇到优先级为紧急的任务 break 并转入手动处理流程。循环体里两个关键字各管一段逻辑，读起来反而是清楚的，前提是过滤条件在前，终止条件在后，别交错在一起。
4.4 性能与可读性权衡：何时避免 Continue 与 Break
性能方面，continue 和 break 的开销在绝大多数语言里可以忽略不计，它们是编译器层面直接处理的控制流跳转，不涉及函数调用、不涉及栈操作。我在 Python 里用 timeit 测过带 continue 的循环和用 if 包住逻辑的循环，差距在纳秒级别，放到实际项目里完全淹没在 IO 和业务计算的开销里。为了性能去纠结用不用 continue 是一种过度优化，我花了很久才把这个执念放下。
可读性上的权衡比性能复杂得多。continue 用在循环体开头做过滤，代码容易读。continue 散落在循环体中间甚至嵌套在好几层 if 里面，读起来就费劲。我有一套自己的判断标准：continue 离循环头部的距离超过十行，或者它所在的 if 分支缩进超过三层，我就会考虑重构。重构的方向一般两个，把过滤逻辑提取成一个独立的函数在循环开头调用，或者把被跳过的逻辑用 if 包起来做成显式分支。哪一种更好取决于被跳过的逻辑有多长。
break 的可读性问题比 continue 少，因为它通常只有一处或者两处，位置也比较好找。麻烦在于 break 在嵌套循环里只跳出最近的一层，外面还有几层在转，如果读代码的人没注意到循环的嵌套层数，会误以为整个循环都停下来了。我在多层嵌套里用 break 会给它配一条注释，写明跳出的是哪一层，给后来的读者省点力气。
4.5 面试与代码审查中的高频问题
面试里关于 continue 和 break 的问题有两类，一类考概念，一类考代码输出。概念题我能背下来的标准答案就那么几句话，真正有意思的是代码输出题。面试官给一段嵌套循环的代码，里面夹杂 continue、break、pass，问你最后打印什么。这类题的陷阱通常在缩进和嵌套层级上，我面过的一个候选人把 pass 当成了类似 continue 的语句，说会跳过当前迭代，实际上 pass 什么都不做，循环体剩下的代码会照常执行。概念记混和代码理解错是两回事，面试官一般更在意后者。
代码审查里的高频问题集中在两个方向。一个是 continue 和 break 影响了循环外面的逻辑但审查的人没看出来，比如调试计数器、资源清理、状态标志的更新写在了循环体后半段，被 continue 跳过了。另一个是循环条件里带了副作用，比如 while i < len(data) and process(data[i]) 这种写法，配合 continue 和 break 会产生很难追踪的执行次数问题。我审查代码的时候看到 while 条件里有函数调用会多留一个心眼。
我还见过一种面试题变体：给一段用 continue 写的代码，让你不用 continue 重写，保持行为一致。这种题目其实没有唯一答案，面试官想看的是你知不知道 continue 等价于一个 if not condition: 的反向包络。能把 continue 改写成反向条件分支，说明对控制流的理解到了可以来回翻转的程度。我自己是写过几年带 continue 的代码之后，才慢慢养成在脑子里自动做这个翻转的习惯。
results = [] for record in records:
if not record.is_valid:
continue
if record.score < 60:
continue
results.append(record.name)
results = [r.name for r in records if r.is_valid and r.score >= 60] count = sum(1 for r in records if r.is_valid and r.score >= 60)
6.1 编写可读 Continue 的命名、注释与结构建议
我在代码审查里见过太多这样的写法：一个函数里塞了五层缩进，每层都有一两个 continue，读代码的时候得在脑子里维护一个“什么情况下会跳到这里”的栈。改起来更痛苦，动一处条件，上下游的跳过逻辑全得重新推一遍。后来我自己写 continue 时养成了一个习惯，把循环体的前半段当成一个“筛选闸门”，所有的 continue 集中放在循环开头，一段接一段往下排，任何一个条件不满足就直接走人。闸门之后的代码只负责处理真正过了筛选的数据，脑子里不用再装着“这种情况还要不要再往下走”的负担。
命名上的建议其实很朴素，但真正做到的人不多。循环变量尽量用能表达语义的名字，record、order、node 比 x、i、tmp 强太多。筛选条件的布尔变量也值得单独拎出来，is_expired、has_permission 这种名字写在 if 里，读者一眼就知道跳过的是什么类型的数据。我见过有人把所有条件塞进一个 if A or B or C or D: continue，读起来像是在解逻辑题，拆成四个独立的 if ... continue 反倒清晰得多，虽然看起来多了几行。
注释这件事，我的态度是“只写给未来的自己看的那一层”。if not line: continue # 跳过空行 这种注释纯属噪音，代码本身已经说清楚了。真正值得写的注释是解释“为什么跳过”——比如某个字段在新版本接口里被废弃了，旧数据可能缺失，这类上下文光看代码是看不出来的。我在自己项目里会写 # 历史数据里 status 可能为空，跳过避免下游 KeyError，过半年回来改代码时省下的时间比写注释多得多。
结构上的一个实用技巧是把复杂的循环体抽成函数。一个循环里如果超过三处 continue，而且每处的判断条件都不短，那基本上就得考虑重构了。把“筛选逻辑”和“处理逻辑”分到两个函数里，循环体只剩下调用和 continue，主干路径一下子就能看清。我在重构一个日志分析脚本时做过这件事，原本两百行的主循环拆成passes_filter() 和 process_entry() 两个小函数，continue 的数量从十一处降到两处，代码行数少了三成，逻辑反而更容易改。
6.2 调试 Continue 相关逻辑：断点、日志与单元测试
continue 的调试难点在于它“什么都没报错”。break 写错位置会让循环提前结束，至少肉眼能看出循环少跑了；continue 写错位置只是把本轮不该跳过的数据跳掉了，程序照常跑完，结果里少了几条记录，不仔细对账根本发现不了。我就被这种东西坑过一回，清洗后的数据比源数据少了一千多条，查了两个小时，最后定位到是一个条件写反了，if x == bad_value: continue 被写成了 if x != bad_value: continue。语义完全颠倒，程序跑得顺畅，结果全错。
断点调试上，我习惯在 continue 那一行前面放一个条件断点，把触发跳过的那些样本打印出来。PyCharm 和 VS Code 都支持条件断点，写在 if 判断后面稍微前一点的位置，条件跟判断本身保持一致，跑起来的时候可以直接看到哪些数据命中了跳过分支。比在循环末尾打日志往回倒推高效得多。批量跑的时候我会改成 logging.debug 记录跳过的行号和原因，事后按日志文件 grep 一遍，能快速统计跳过的分布。
日志的关键是区分“正常跳过”和“意外跳过”。业务逻辑里本来就该跳过的数据，比如已删除的记录、重试次数超限的请求，记 DEBUG 级别就够了，跑起来的时候默认不输出，需要排查时开一下。意料之外的跳过才值得 WARN 或 ERROR，比如解析失败、字段缺失这类“不该发生但确实发生了”的情况。我早期写代码不分级别，所有跳过都打 INFO，跑一天下来日志几个 G，翻的时候根本找不到重点，后来把日志策略梳理了一遍，排查效率翻了好几倍。
单元测试是防御 continue 逻辑出错的最后一道关卡。测试用例要覆盖“该跳过的”和“不该跳过的”两边，很多人只写前面一类，测试数据全是需要过滤的异常值，跑通了就以为没问题，实际上正常数据的处理路径根本没测到。我在项目里习惯给每个带 continue 的循环写至少三个 case：一个触发跳过、一个正常处理、一个边界值（比如刚好等于阈值），三个都过了心里才踏实。pytest.mark.parametrize 很适合干这个活，一张表列出来，跑起来一目了然。
6.3 常见反模式：过度嵌套、隐藏副作用、误用跳过
过度嵌套是我见过最普遍的反模式。一个 for 里面套一个 if，if 里面套一个 for，内层再套一个 if，最里面才 continue，缩进已经顶到屏幕右边缘了。这种代码读起来累，改起来更容易出事。处理它的办法我在前面章节提过，把内层循环抽函数，或者用早返回的写法把过滤条件提前。continue 本身是压缩缩进的工具，被用成加深嵌套的理由就完全反过来了。
隐藏副作用是更隐蔽的一类问题。循环体里带 continue，跳过之前偷偷修改了外部状态，比如往一个列表里追加了半成品、给计数器加了一、发了半条日志。跳过之后的迭代看到这些“残留”，行为就可能跟预期不符。我调过一个批量导入的脚本，每轮循环开头 results.append({})，读到坏行就 continue，结果最后 results 里多出一堆空字典。修法是把状态修改挪到 continue 之后，保证只有真正处理完成的数据才会留下痕迹。这种 bug 特别容易在测试覆盖不足的时候漏过去，因为单看每一条数据的处理逻辑都是对的。
误用跳过是第三类。有些场景下 continue 看起来顺手，实际上掩盖了本该显式处理的逻辑分支。比如一个函数负责汇总数据，遇到不满足条件的记录直接 continue，什么都不记录。数据跑完之后汇总结果对不上，查起来才发现是被静默跳过了。更好的做法是把这类记录归到一个“异常集合”里，最后一起输出，或者至少打个 WARN。跳过是手段，不是目的，跳过之后那些数据去了哪里，写代码的人心里得有一个清楚的账。
还有一种误用是把 continue 当成 return 用。函数体里一个循环，循环体里遇到某个条件就 continue，控制流继续在循环里转，函数后面的代码一个也不执行——如果作者的本意是“这事儿办完了退出函数”，那写 return 才对，continue 会让循环白跑剩下的迭代。我在 review 新人代码时见过好几次这种用法，问原因多半是“当时想的是跳过这次，后来发现其实应该整个结束”。这种语义偏差在运行结果上不一定看得出来，性能上浪费得很明显，逻辑上也容易埋下隐患。
6.4 学习路径与搜索建议：Continue statement in Python、Continue vs Break in Programming
想系统学 continue，我建议的起点是找一份 Python 官方文档里控制流那一章读一遍。官方文档写得简短，但每一句都精准，for 循环的 else 子句跟 continue 的交互、try/finally 的边界情况，这些细节散落在文档的不同角落，串起来读一遍比零散地搜博客质量高得多。读完文档再去跑几个小例子，几种控制流的组合方式亲手试一遍，记忆才扎实。
Continue statement in Python 是英文搜索里最值得查的关键词。英文社区关于这方面的问答质量不低，Stack Overflow 上高赞回答经常把几种边界情况一起列出来，还会顺手提到版本差异。搜索的时候加上 Python 3 或者具体的场景词，比如 continue statement in Python for loop、continue in while loop Python，结果会更聚焦。中文搜索的话，用“Python continue 用法”或者“Python continue 循环”也能找到不少资料，但质量参差，看几篇互相印证一下比较稳妥。
Continue vs Break in Programming 这个关键词适合跨语言对比。搜出来的文章常常把 continue、break、return、pass 放在一起横向比较，读完一遍能建立起一张比较清晰的控制流地图。我早期看这类文章时常有个体会：单个关键字在某个语言里怎么用，看文档就够了；几个关键字放在一起比较，哪一个是“跳过”、哪一个是“终止”、哪一个是“占位”、哪一个是“交还”，这些概念层面的区别，才是真正影响写代码时决策的东西。多语言对照着看，理解会更深。
真到了要用于项目的阶段，我的建议是找一份开源项目里 continue 用得比较多、写得比较规范的代码来读。Pandas、Requests 这类项目的源码里控制流写得很讲究，continue 的位置和条件都经过多次审查，比教程里的玩具例子更接近真实场景。读的时候带一个问题：“如果这里不用 continue，改成 if 嵌套，会变成什么样？” 自己动手改一两个地方对比一下，感受会很直接。
6.5 总结：把 Continue 作为清晰控制流的工具
回过头看这一路写下来的内容，从最开始讲 continue 的词义、它在各种语言里的位置，到语法执行机制、跟 else、try/finally、with 的交互，再往后的扩展用法和反模式，所有内容指向同一个点：continue 不是“循环里的一个小助手”，它是控制流里的一等公民，用得好能把代码写得又短又清楚，用不好会造出一堆隐性 bug 和难缠的调试现场。
我自己对 continue 的态度，是这些年慢慢形成的一种偏好。数据过滤、条件筛选、跳过异常样本，这类场景下 continue 几乎是必选项，写出来的代码读起来像是在说“这一条不要，下一条”，自然又直接。跨层控制、复杂状态转移、需要精细资源管理的场景，continue 就不一定是最佳选择，函数抽取、标志变量、带标签的循环（在支持的语言里）都比强塞 continue 要清楚。语言是工具，不是教条，判断标准是读代码的人能否在最短时间内理解控制流走向。
最后想留的是一句话：continue 的价值在于它能让“处理主干”和“筛选条件”在视觉上分开。主干代码贴着左边、一行接一行往下走，筛选代码集中在循环开头、一个 if 加一个 continue，两者泾渭分明。代码的清晰度很大程度上来自这种视觉上的分层，continue 恰好在合适的场景里提供了这么一个工具。把这一点抓住，剩下的细节都是这之上的展开。
