std::unreachable() 仅在编译器能静态证明路径不可达且启用足够优化级别（GCC/Clang -O2、MSVC /O2）时才触发代码删除；GCC 13+/Clang 14+/MSVC 19.35+ 支持标准实现，低版本或未达标配置下仅为无操作或调用 std::terminate。
它只在编译器能静态证明路径不可达、且构建配置匹配时才真正删代码——写错位置或开错优化等级，std::unreachable() 就是一条没用的空语句。
哪些编译器版本和优化级别下 std::unreachable() 才生效
它不是语言特性，而是编译器后端的剪枝信号。不满足条件时，它不会报错，也不会警告，更不会优化。
- GCC 13+ / Clang 14+ / MSVC 19.35+ 才提供标准实现；GCC 12 或 Clang 13 可能识别函数签名但不触发控制流优化
- 必须开启
-O2（GCC/Clang）或/O2（MSVC）；-O1下 Clang 常忽略，-O0下它会调用std::terminate（调试时崩溃，而非优化） - 启用 LTO（
-flto）可让不可达性跨函数传播，但需所有目标文件统一启用，否则无效 - 验证是否生效最可靠方式：
g++ -O2 -S生成汇编，搜索对应函数，看含std::unreachable()的分支是否消失、变成ud2（x86）或被跳转指令绕过
在 switch 中用 std::unreachable() 替代 default 的真实风险
这不是“补全语法”，而是向编译器押上逻辑正确性。一旦出错，程序不会报错，只会 UB —— 静默跳过、寄存器错乱、或后续指令执行错位。
- 对
enum class使用时，必须确保每个命名值都被case显式列出；新增枚举项却漏改switch，运行时遇到新值即 UB - 对裸
int、网络输入、用户读入等运行时值滥用default: std::unreachable();，编译器无法静态证明不可达，优化不发生，反而埋下崩溃隐患 - 某些
clang-tidy规则（如bugprone-branch-clone）会把std::unreachable()当作“分支已完备”信号，跳过枚举完整性检查，掩盖真实遗漏 - 更安全做法：先用
static_assert验证枚举值数量（例如配合std::to_underlying和数组大小），再在default中放std::unreachable()
std::unreachable() 和 __builtin_unreachable 的实际差异不止是名字
它不是语法糖封装，而是在模板实例化、调试信息、跨平台行为上存在可观测区别。
立即学习“C++免费学习笔记（深入）”；
-
std::unreachable是 C++23 标准函数，声明在<utility>，类型安全，不污染全局命名空间；__builtin_unreachable是 GCC/Clang 扩展，MSVC 不支持，必须用宏适配 - 在模板中，
std::unreachable()可参与 SFINAE（虽不推荐），而__builtin_unreachable()在非实例化模板里可能引发硬错误 - GDB 调试时，
__builtin_unreachable常被标记为 “no debug info”，GDB 直接跳过该行；std::unreachable更可能保留符号，便于定位崩溃点（尽管本不该到达） - 部分旧版 Clang 对
__builtin_unreachable的死存储删除更激进；而早期std::unreachable实现可能被当作普通函数调用处理，延迟优化
它真正的价值不在“加了就快”，而在你愿意为一行提示承担逻辑绝对正确的责任——编译器不会替你检查枚举是否漏项，也不会验证输入是否真在理论范围内。一旦路径实际可达，后果不是慢，而是不可预测。
