std::expected适用于预期可能失败且必须显式处理的场景（如文件打开、JSON解析），不适用于逻辑崩溃或轻量返回；链式调用推荐and_then扁平化，需自行实现；error宜用enum class而非std::string；不可混用throw与expected，须注意move语义和value()异常。
std::expected 什么时候该用，什么时候不该用
不是所有错误都要用 std::expected。它适合「预期中可能失败、且调用方必须显式处理」的场景，比如文件打开、JSON 解析、网络响应解码——失败是常态，不是异常。反过来，如果函数失败意味着程序逻辑崩溃（如空指针解引用），用 throw 更合适；如果只是需要返回布尔值+输出参数，std::optional 或 std::pair<bool t></bool> 更轻量。
链式调用中如何避免嵌套 if 或手动 unpack
直接写 if (auto r = parse_json(); r.has_value()) { auto x = r.value(); ... } 会快速变深。推荐用 and_then（C++23）或自定义扩展来扁平化：
auto result = read_file("config.json")
.and_then(parse_json)
.and_then(validate_config)
.and_then(apply_config);
注意：标准库目前（C++23）尚未提供 and_then，需自行实现或依赖 std::expected 的提案补丁（如 libstdc++ 13+ 或 MSVC 19.37+ 已部分支持）。若不可用，可用 lambda + 模板推导模拟：
-
and_then的签名应为template<class F> auto and_then(F&& f) &&，要求F返回std::expected<U, E> - 若
f抛异常，std::expected不捕获——这和std::optional一致，不是 bug，是设计选择 - 不要在
and_then里做资源清理，错误路径需靠 RAII 或显式error()分支处理
error 类型选 std::string 还是枚举？
用 enum class（如 enum class ParseError { InvalidFormat, MissingField, OutOfRange };）比 std::string 更安全、更易测试、更省内存。但调试时缺少上下文信息——建议组合使用：
立即学习“C++免费学习笔记（深入）”；
- 定义错误枚举作为主类型：
std::expected<Config, ParseError> - 在日志或调试输出中，用
switch匹配枚举并附加动态信息：case ParseError::MissingField: log("missing field: " + field_name); - 避免把
std::exception_ptr当 error 类型塞进std::expected，它不满足std::is_copy_constructible_v要求（除非手动包装）
和传统异常对比时最常踩的坑
最大的错觉是“用了 std::expected 就不用 try/catch 了”——其实它们解决不同问题。常见误用：
- 在底层函数里混用：一个函数用
std::expected返回，另一个同级函数却throw，调用链被迫同时处理两种错误机制 - 忽略 move 语义：
std::expected<BigObject, Error>在拷贝时可能触发昂贵复制，确保BigObject可移动，且传递时用std::move(r).value()显式转移 - 误以为
std::expected::value()安全：它和std::optional::value()一样，失败时抛std::bad_expected_access，不是静默失败
真正优雅的链式调用，不在于语法多简洁，而在于每个环节的错误语义是否清晰、能否被静态检查、以及是否让调用方无法忽略失败路径——这点上，std::expected 比异常更严格，也更容易被忽视细节。
