[[fallthrough]]：C++里那个被低估的“我故意不加break”的声明

写过 switch 的人，大概都踩过这个坑：逻辑明明该在某个 case 结束，却因为少打了一个 break，程序一路穿透到下一个分支，结果输出了个意料之外的结果。调试时盯着代码发呆三分钟，改完 break 后长舒一口气——这种经历，谁还没两三回？

但你有没有想过：如果某次穿透，就是你想要的呢？
不是疏忽，不是 bug，而是设计如此。这时候，[[fallthrough]] 就不是语法糖，而是你写给编译器和队友的一句轻声提醒：“这儿没忘写 break，我就是想往下走。”

它不是“允许穿透”，而是“声明穿透意图”

很多人初看 [[fallthrough]]，下意识觉得它是开启某种开关，让编译器“允许” fallthrough。错。它不改变行为，只做一件事：告诉编译器“我知道这里会穿透，别警告我”。

换句话说：

• 没加 [[fallthrough]]，但代码实际穿透了 → GCC/Clang 默认报 -Wimplicit-fallthrough 警告；
• 加了 [[fallthrough]]，且下一行确实是另一个 case 或 default → 警告消失；
• 加了 [[fallthrough]]，但下一行是 return、throw 或空行 → 编译器反而报错（[[fallthrough]] 无意义）。

这很关键：它不控制流程，只标注意图。 类似你在 Git 提交里写 “fix: 修复空指针” 而不是 “fix bug”，后者模糊，前者清晰可追溯。

一个真实场景：状态机里的自然过渡

假设你写一个简易的 HTTP 状态解析器，要处理 1xx（信息响应）、2xx（成功）、3xx（重定向）三类：

switch (status_code / 100) {
    case 1:
        handle_info();
        [[fallthrough]]; // 明确：1xx 也属于“非错误响应”
    case 2:
        handle_success();
        [[fallthrough]]; // 同理：2xx 也不触发错误逻辑
    case 3:
        handle_redirect();
        break;
    default:
        handle_error();
        break;
}

这里，1xx 和 2xx 都需要调用 handle_success()，但 1xx 还要额外执行 handle_info()。用 fallthrough 实现，比复制粘贴逻辑干净，也比写 if (code < 400 && code != 101) 更贴近语义。

而 [[fallthrough]] 的存在，让这段代码在团队协作中不会被新成员误删——他看到这个属性，第一反应是：“哦，这是有意为之，先别动”。

为什么不用注释？比如 // fall through

试过就知道：注释太弱了。

• 它不参与编译检查；
• 它可能被复制粘贴到错误位置（比如 [[fallthrough]] 下面跟了个 return，编译器立刻报错，注释不会）；
• 它无法被静态分析工具识别，IDE 不能高亮、不能跳转、不能批量检查是否遗漏。

更现实的是：注释会过期，属性不会。
去年我维护一段老代码，发现三处 // fall through，其中一处下面其实是 continue; —— 注释早已失效，但没人发现。换成 [[fallthrough]]，CI 构建当场失败，问题立刻暴露。

常见误用与避坑点

• ❌ [[fallthrough]] 必须紧挨着上一个 case 的末尾（或其后紧跟的空行），不能隔语句；
• ❌ 不要把它放在 default: 后面（除非你真想穿透到 switch 外——这不可能，语法不允许）；
• ✅ 支持 C++17 及以上，但 GCC 7+、Clang 4+ 已完整支持，无需担心兼容性；
• ✅ 可以和 [[nodiscard]]、[[maybe_unused]] 等共存，互不干扰。

一个小技巧：如果你的项目启用了 -Wimplicit-fallthrough，但某些 legacy 代码暂时没法改，宁可先加 [[fallthrough]] 标注，再排期重构，也不要关掉警告——关警告就像拔掉烟雾报警器来解决厨房油烟。

它真正解决的，是“信任成本”

写代码最耗神的，往往不是逻辑本身，而是“这段代码到底想干什么”。
一个没有 break 的 case，像一句没说完的话；别人读到，得停下来猜：是作者忘了？还是底层协议真要这样跳？还是历史原因硬凑的？

[[fallthrough]] 把模糊地带收窄成明确契约。它不拯救烂设计，但它让好设计更容易被读懂、被信任、被放心修改。

下次当你又在 case 后停顿半秒，犹豫要不要加 break 时，不妨多问一句：
“如果我不加，是不是恰恰表达了我想表达的？”
如果是，那就大大方方写上 [[fallthrough]]——这不是偷懒，是精准表达。