std::expected 和 std::print 是 C++23 中真正落地、开箱即用的两个关键特性——前者已进入 GCC 13.4+/Clang 17+ 的 头文件（需 -std=c++23），后者在 GCC 14/Clang 18 中通过 提供基础支持，但目前仍处于“部分实现”状态，std::print 尚未完全标准化（例如不支持格式化参数自动推导，std::println 也暂未加入）。

std::expected 怎么用？别直接 return T 或 throw

它不是 optional 的替代品，也不是异常的简化版；它是为「预期会失败、且错误原因必须被调用者看到」的场景设计的。典型如配置解析、IO 读取、除法、JSON 解析等。

• 函数签名必须显式写出 std::expected，不能靠隐式转换糊弄编译器
• 成功时用 return value;（自动转为 expected），失败时必须用 return std::unexpected(e);，写 return e; 会编译失败
• 错误类型 E 推荐用 enum class 或 std::error_code，避免裸字符串（std::string 会引发不必要的拷贝和内存分配）
• 不要在循环里频繁构造 std::expected<:vector>, MyError>——大对象移动成本高，优先考虑小而轻的 E 类型

#include 
#include 
enum class ParseError { Empty, Overflow };
std::expected parse_int(const char s) {
if (!s || s == '\0') return std::unexpected(ParseError::Empty);
try {
return std::stoi(s);
} catch (const std::out_of_range&) {
return std::unexpected(ParseError::Overflow);
}
}

std::print 现在能放心用吗？先看你的编译器和需求

截至 2026 年初，std::print 在主流编译器中仍属实验性支持：GCC 14 默认关闭，需加 -D__STDC_FORMAT_MACROS 并链接 libstdc++-experimental；Clang 18 仅支持无格式化的 std::print("hello")，不支持 {} 占位符或 std::println。

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

• 如果你只是想替代 printf 做简单日志输出，且能接受编译器特定行为，可以试用，但别用于跨平台发布代码
• 它不兼容 std::format 的全部语法（比如宽度填充、对齐标志在部分实现中被忽略）
• std::print 不是线程安全的——多个线程同时调用可能交错输出，std::cout 同样有这问题，但至少语义明确；std::print 的“原子性”承诺尚未兑现
• 当前更稳妥的选择仍是 std::format + std::cout 组合，或继续用 fmt::print（第三方，稳定、高效、功能全）

and_then / or_else 链式调用为什么容易翻车？

这两个方法看着像 Rust 的 and_then，但 C++ 版本对 lambda 返回类型的推导非常严格：返回值必须精确匹配下一个 std::expected 的模板参数，否则编译失败——连 std::expected 和 std::expected 都不能混用。

• .and_then 的 lambda 必须返回 std::expected（注意：E 必须和原 expected 的错误类型完全一致，不能是可转换的）
• .or_else 的 lambda 必须返回 std::expected，且 F 要能赋值给原 E，否则报错
• 嵌套太深时，类型推导失败信息极难读，建议拆成独立命名函数，而不是一长串 inline lambda
• 别试图用 and_then 替代 if (e.has_value())——简单判断就别硬套链式，可读性反而下降

真正要注意的是：std::expected 的错误处理契约是「编译期强制」，但它的运行时行为完全零开销——没有虚函数、没有动态分配、没有栈展开。这意味着一旦你写错类型签名或漏掉 std::unexpected，编译器立刻拦住你；可一旦通过，性能就和手写 if-else 一样干净。这种确定性，恰恰是它最难被替代的地方。