std::unreachable 在 GCC 13+/Clang 14+/MSVC 19.35+ 且开启 -O2 或更高优化时才真正起作用；Debug 模式下无效，低版本需用内置函数替代，且仅适用于编译器可静态证明不可达的路径。
std::unreachable 在什么编译器版本和优化级别下才真正起作用？
它不是“写了就优化”，而是高度依赖编译器实现和构建配置。GCC 13+、Clang 14+ 和 MSVC 19.35+ 才提供标准 std::unreachable（C++23），且必须开启至少 -O2（GCC/Clang）或 /O2（MSVC）。低于这些版本，__builtin_unreachable() 或 __assume(0) 是实际可用的等价物，但行为不完全一致。
- Clang 在
-O1下可能忽略std::unreachable，直到-O2才触发控制流剪枝 - 启用 LTO（
-flto）后，跨函数传播效果更明显，但会增加链接时间 - Debug 模式（
-O0）下，多数编译器把它当空语句，不报错也不优化
用 std::unreachable 替换 default 分支时要注意哪些陷阱？
常见错误是把它当成“兜底注释”，误以为能替代逻辑完整性检查。编译器只信你写的控制流，不信你的业务约束。
- 枚举未覆盖所有值时加
default: std::unreachable();，但如果枚举被扩展（比如新增成员）、而 switch 没同步更新，运行时遇到新值就会 UB —— 不崩溃，直接跳进不可预测状态 - 对非枚举整型（如
int）滥用：例如switch(x) { case 0: ... case 1: ... default: std::unreachable(); }，若x实际为 2，行为未定义，且编译器不会警告 - 某些静态分析工具（如 clang-tidy）会把
std::unreachable()当作“已覆盖全部分支”信号，跳过枚举完备性检查，掩盖真实缺陷
正确做法是：仅用于**编译器可静态证明不可能到达**的路径，比如 fully-covered enum class + [[nodiscard]] 构造函数 + 无外部输入的纯内部调度。
和 __builtin_unreachable 相比，std::unreachable 有哪些实际差异？
表面是标准化封装，实则影响代码生成质量与可移植性。
立即学习“C++免费学习笔记（深入）”；
-
std::unreachable是 C++23 标准函数，类型安全，不污染全局命名空间；__builtin_unreachable是 GCC/Clang 扩展，MSVC 不支持，需宏适配 - 在模板中使用时，
std::unreachable可参与 SFINAE（虽通常不该这么用），而内置函数在非实例化模板中可能导致硬错误 - 部分旧版 Clang 对
__builtin_unreachable的控制流分析更激进，比如提前删除后续 dead store；而std::unreachable在早期实现中可能被当作普通调用处理，延迟优化 - 调试信息方面：
__builtin_unreachable常被编译器标记为 “no debug info”，导致 GDB 跳过该行；std::unreachable更可能保留符号，便于追踪崩溃点（尽管仍不该到达）
std::unreachable 影响内联和函数属性推导吗？
会影响，但方式隐蔽。编译器看到 std::unreachable 后，会重新评估函数的“可能返回路径”，进而改变内联决策和 [[noreturn]] 推导。
- 含
std::unreachable的函数，即使没有显式[[noreturn]]，也可能被编译器判定为“永不返回”，从而禁用 tail-call 优化或影响调用约定选择 - 若函数末尾是
std::unreachable()，编译器可能省略栈帧清理代码（如mov rsp, rbp; pop rbp），减小代码体积 - 在 inlining 场景中，调用者若在内联后暴露出新的不可达路径，可能触发额外的死代码消除（DCE），但这也意味着原函数不能有副作用——否则 DCE 会误删
最易被忽略的一点：它让编译器相信“此路径之后无有效状态”，所以任何在此之后的变量生命周期、析构逻辑、甚至 volatile 访问，都可能被彻底抹除。别指望它后面还能打日志或设断点。
