编译器警告“unannotated fall-through”是为了提醒开发者显式标注 switch 中的穿透行为，C++17 起标准化 [[fallthrough]] 属性，须独占一行、位于穿透分支末尾，不可加空语句或分号，且仅在 case/default 内有效。
为什么编译器会警告“unannotated fall-through”
当你在
的某个
分支末尾没写
，又没加
，现代 C++ 编译器（如 GCC、Clang）默认会报
警告。这不是语法错误，但它是编译器在提醒：你可能忘了写
，也可能是真想穿透——但它没法自动区分。
这个警告从 C++17 开始被标准化支持，目的是提升
逻辑的可读性和安全性。不处理它，轻则 CI 报黄，重则被静态分析工具拦截。
仅当控制流**显式落到下一个
或
标签之后**时才触发该警告
必须放在会穿透的分支**最后一行**（或紧挨着下一行），且只能用于
/
内部
它不改变任何运行时行为，纯属编译期注解
怎么正确写
它不是函数调用，也不是宏，是标准属性（attribute），语法非常严格：必须独占一行（或作为该行最后一个非注释元素），前面不能有其他语句，后面不能跟分号。
常见写错方式：
立即学习
“
C++免费学习笔记（深入）
”；
写成
—— 多了分号，编译失败
写成
—— 属性和语句混在同一行，无效
写在
后面 —— 属性位置失效，警告还在
跨平台项目中用了
（GCC）或
—— 不符合 C++17 标准，可移植性差
正确示例：
C函数速查手册（CHM版）
C函数速查手册（CHM版）
下载
和空
的关系
空
（比如
连写）本身不触发
警告，因为没有“执行完语句后掉下去”的语义。但一旦你在其中加了哪怕一条语句，就必须标注。
→ 安全，无需标注
→ 编译器认为
执行完后会落到
，必须加
→ 合法，但语义奇怪（没做任何事就穿透），通常说明设计可优化
注意：有些团队禁用空
连写，强制拆成带
的形式，只为统一穿透表达方式，方便 grep 或自动化检查。
兼容性与替代方案
C++17 是
的起点，低于此标准（如 C++14）无法使用。如果项目需兼容旧标准，常见做法是用编译器特定属性兜底，但得配合宏封装：
不过要注意：
在 Clang/GCC 下不会抑制警告，它只是让代码能编译；真正起作用的仍是标准属性。所以升级到 C++17 是最干净的解法。
真正容易被忽略的是：
只能出现在
或
标签下，不能放在函数开头、循环里，也不能用来“跳过”
之外的控制流（比如想从
里穿透到下一个
？不行，语法不允许）。
switchcasebreak[[fallthrough]]unannotated fall-throughbreakswitchcasedefault[[fallthrough]]casedefault[[fallthrough]][[fallthrough]];[[fallthrough]] break;break;__attribute__((fallthrough))[[clang::fallthrough]]switch (x) {
case 1:
do_something();
[[fallthrough]]; // ✅ 正确：独占一行，带分号
case 2:
handle_two();
break;
}[[fallthrough]]casecasecase 1: case 2:fallthroughcase 1: case 2:case 1: foo(); case 2:foo()case 2[[fallthrough]]case 1: [[fallthrough]]; case 2:case[[fallthrough]][[fallthrough]]#if __cplusplus >= 201703L
#define FALLTHROUGH [[fallthrough]]
#elif defined(__clang__)
#define FALLTHROUGH [[clang::fallthrough]]
#elif defined(__GNUC__) && (__GNUC__ >= 7)
#define FALLTHROUGH [[gnu::fallthrough]]
#else
#define FALLTHROUGH do {} while(0) // 空语句，无副作用
#endifdo {} while(0)[[fallthrough]]casedefaultbreakifcase