跳转语句

跳转语句会改变“按顺序执行”这一默认控制流。它们很有用，但也最容易让代码失去线性可读性。本节给出整体视图，后续小节分别讨论 break、continue、return 和 goto 的边界与用法。

1. 设计原则

跳转不是坏事，失控跳转才是坏事。只要跳转方向清晰、作用范围可预测、资源释放路径完整，跳转语句可以显著简化错误处理和循环退出逻辑。相反，跨层级、跨语义块的随意跳转会迅速放大维护成本。

2. 如何选择

在循环中提前结束当前层迭代，优先用 break 与 continue；在函数层面结束流程，使用 return；只有在结构化控制流无法清晰表达清理路径时，再考虑 goto。这个顺序能让绝大部分代码保持可读。

3. 跳转与资源释放

跳转语句最容易出问题的地方不在“能不能跳”，而在“跳走后是否遗留未释放资源”。当代码涉及文件句柄、动态内存或锁对象时，每条跳转路径都应落到一致的清理点，这也是为什么很多底层 C 代码会在函数尾部集中写释放逻辑。

#include <stdio.h>
#include <stdlib.h>

int parse(FILE *fp) {
    char *buf = NULL;
    int ok = 0;

    buf = malloc(1024);
    if (buf == NULL) {
        return 0;
    }

    if (fgets(buf, 1024, fp) == NULL) {
        goto cleanup;
    }

    ok = 1;

cleanup:
    free(buf);
    return ok;
}

运行结果：该代码块主要用于语法或结构说明，单独运行通常无终端输出。

这个模式的核心是“每条失败路径都能回到同一个清理出口”，而不是鼓励滥用 goto。

4. 与后续章节的关系

本节讲的是语句级跳转；后面的函数、并发、错误处理章节会继续展示这些跳转语句在真实工程中的组合方式。只要保持路径可读、清理完整，跳转就是可靠工具，而不是风险源。

5. 跳转路径的核对方法

阅读跳转密集代码时，可以先列出“所有出口点”和“每个出口前必须完成的收尾动作”，再逐条核对每个 break、continue、return、goto 是否都满足该约束。这个检查方式简单但有效，尤其适合资源管理较多的函数。

6. 风格一致性建议

同一模块里建议固定一种跳转组织风格，例如“失败前向跳到统一清理标签”或“早返回 + 局部清理”。风格统一后，读者能更快预测路径结构，评审时也更容易发现遗漏分支。

7. 跳转与作用域约束

跳转语句虽然改变控制流，但不会绕过语言层面的作用域与对象生命周期约束。特别是 goto 不能任意跳入某些不满足约束的内部作用域，return 会结束当前函数自动存储期对象生命周期。把“路径变化”和“语义约束”同时考虑，才能写出可验证的跳转逻辑。

8. 优先写出单向可追踪路径

跳转结构最容易维护的形态通常是单向前进：循环内部的 break/continue 只影响当前层，函数失败路径统一向函数尾部收束，正常路径直达返回点。只要路径方向和职责清楚，跳转语句就会成为简化复杂流程的工具，而不是复杂度来源。

习题