C++26的inspect语法不用于简化if-else链，而是专用于结构化解构与类型/值联合匹配；它只支持模式匹配（如int i、std::pair p），不接受布尔表达式作为分支条件。

C++26 的 inspect 语法（目前处于 TS 阶段，尚未最终定稿）不会简化现有 if-else 链——它根本不是为替换传统控制流设计的，而是专用于结构化值解构 + 类型/值联合匹配的全新机制。你若直接拿它去“优化”一串基于布尔条件的 if (x > 0 && y 判断，会发现它不支持、不可用、甚至编译不过。

inspect 只匹配可解构的“模式”，不是通用条件表达式

inspect 的核心是「对一个表达式的结果进行类型检查 + 成员/字段/枚举值的结构化提取」，类似 Rust 的 match 或 Swift 的 switch，但要求目标类型支持 operator==、std::is_constructible_v 等约束，且每个 when 分支必须是合法的模式（如 int i、std::pair p、MyVariant v）。它不接受任意布尔表达式作为分支条件。

• ✅ 支持：

  inspect (v) {
    when (int i) { /* v 是 int，i 绑定其值 */ }
    when (std::string const& s) { /* v 是 string */ }
    when (std::pair p) { /* v 可隐式转为 pair */ }
  }

• ❌ 不支持：

  inspect (x) {
    when (x > 0 && x < 10) { /* 编译错误：这不是模式，是布尔表达式 */ }
    when (x % 2 == 0) { /* 同样非法 */ }
  }

真正能替代 if-else 链的场景：variant / enum class + 解构

只有当你原本的 if-else 实际上是在做「根据变量的动态类型或枚举值分发逻辑」时，inspect 才有明显优势。比如处理 std::variant 或 std::expected：

• 传统写法冗长且易漏 std::holds_alternative 检查和 std::get 强制转换
• inspect 自动完成类型判别 + 安全绑定，避免手动 std::get_if 和未定义行为
• 分支顺序仍重要，但语义更清晰：每个 when 是「我期望这个形状」，而非「如果满足这个布尔条件」

与 if-else 性能对比：无额外开销，但不等价

inspect 在底层通常编译为跳转表（对 enum）或一系列 typeid / vtable 比较（对 variant），和手写 if-else 的运行时成本基本一致——它没做魔法优化，只是把样板代码（类型检查 + 提取）收进语法糖里。但要注意：

立即学习“C++免费学习笔记（深入）”；

• 不能混用：你无法在一个 inspect 中既匹配类型，又执行 if (ptr != nullptr) 这类运行时判断
• 错误处理需另写：比如 when (std::unexpected e) 只捕获 error case，success case 还得单独写 when (T t)，不能像 if (auto r = f(); r.has_value()) 那样单次求值复用
• 调试体验不同：某些调试器尚不识别 when 分支断点，可能需回退到展开后的汇编看跳转

真正容易被忽略的一点：C++26 inspect 要求所有 when 分支覆盖全部可能类型（exhaustiveness），否则编译报错——这看似是安全特性，但如果你用的是自定义 variant 且忘了加新类型分支，或者依赖 ADL 查找失败导致某个 when 不匹配，编译就会中断。它不提供 else 或 when _ 通配（当前草案中尚未引入下划线通配符），容错性比手写 if-else 更低。

https://www.php.cn/faq/1991869.html