C# 15 中的标记 break：实际应用

C# 15 中的标签化 break 和 continue：何时以及为何使用新的循环标签

C# 15 引入了备受期待却颇具争议的功能——标签化 break 和 continue。尽管社区部分人士提出批评，这一新增特性解决了在处理嵌套循环和 switch 表达式时出现的一些具体问题。它特别适用于需要退出不是最内层代码块，而是外部循环的情况，而无需使用 goto 或标志变量。

退出嵌套结构的问题

传统上，C# 无法在使用 break 或 continue 语句时明确指定要退出哪个循环。这导致需要引入额外的逻辑标志、将代码拆分成方法，或者使用 goto——这违背了干净代码原则。例如，在处理二维数据结构时，往往需要在满足特定条件时立即停止所有迭代：

string foundValue = null;
bool shouldBreak = false;

for (int x = 0; x < xMax; x++)
{
    for (int y = 0; y < yMax; y++)
    {
        foundValue = GetValue(x, y);

        if (foundValue == targetValue)
        {
            shouldBreak = true;
            break;
        }
    }

    if (shouldBreak)
    {
        break;
    }
}

ProcessValue(foundValue);

这种方法不仅使代码变得杂乱，还会带来错误风险——例如，即使未找到值也调用 ProcessValue。将逻辑提取到单独方法可以提升可读性，但并非总是适用，尤其是当循环状态依赖多个外部变量时。

标签化 break/continue 的实际应用场景

使用标签的最具说服力的场景是循环内的 switch。没有标签化 break，就无法从 case 分支中退出外部循环。过去，开发者不得不使用 goto 或将逻辑包装在 lambda/局部函数中。现在，解决方案变得简单明了：

outer: foreach (var item in collection)
{
    switch (item.Type)
    {
        case ItemType.StopAll:
            break outer;
        case ItemType.SkipGroup:
            continue outer;
    }
}

这样的代码清晰表达了意图：break outer 会终止整个循环，而 continue outer 会跳到外部循环的下一个迭代。这在解析器、有限状态机和事件路由系统中特别有用。

何时避免使用标签

尽管技术上正确，标签化 break 和 continue 并不应随处使用。只有在替代方案会降低可读性或性能时，才有理由使用。在大多数情况下，优先选择：

• 将逻辑提取到单独方法中使用早返回（early return）。
• 使用 LINQ 操作符（FirstOrDefault、Any 等）来查找值。
• 仅在简单嵌套结构中使用标志。

标签的使用有理有据的情况包括：

• 循环内包含 switch 且有多个 case 需要在外层循环级别进行流程控制。
• 性能至关重要，且由于开销而不宜提取到方法中。
• 逻辑无法分解而不会丢失语义完整性。

方案对比：标签 vs. 重构

让我们考虑三种实现相同场景的方式——在矩阵中搜索值，并支持跳过行和提前终止：

方案 1: 标志

— 优点：兼容所有 C# 版本。

— 缺点：认知复杂度高，容易出错。

方案 2: 拆分成方法

— 优点：可读性好、可测试、符合 SOLID 原则。

— 缺点：可能增加调用栈深度。

方案 3: 标签化 break/continue

— 优点：紧凑、精确表达意图。

— 缺点：适用范围有限、对部分开发者不熟悉。

选择取决于上下文。对于业务逻辑，优先方案 2。对于系统代码或解析器——方案 3。

要点

• C# 15 中的标签化 break 和 continue 解决了狭窄但真实的问题：从嵌套 switch 或循环中进行流程控制。
• 不要用标签取代重构：如果逻辑复杂，最好提取到单独方法中。
• 经典应用场景——通过 foreach 处理集合并使用 switch，其中某些 case 需要终止或跳过外部循环的迭代。
• 该特性处于 Open 状态，但已被 C# 语言组的工作集接受。
• 避免比较非等价示例：旧代码和新代码应解决相同任务。

— Editorial Team