std::expected 替代异常的代价是强制显式错误处理、丧失透传能力及移动后状态不确定风险；需统一错误类型、避免模板爆炸，并谨慎用于异步流程。
std::expected 在业务错误链中替代 throw/catch 的真实代价
直接用 std::expected 替代异常，不是“更优雅”，而是为了把错误传播路径从栈展开（stack unwinding）强制收束为值传递——这对大型项目意味着可静态分析的错误流向、无隐式控制流、以及线程安全的错误携带能力。但代价是：所有中间层函数必须显式处理或转发 std::expected，否则编译失败；且不能像异常那样跨多层“透传”而不写代码。
- 若某函数返回
std::expected<t errorenum></t>，调用方必须用.has_value()、.value()或.error()显式分支，编译器不帮你跳过 - 嵌套调用链中，
and_then可链式转发成功值，但一旦某步返回std::expected<u e></u>且E与上游不兼容，就得手动map_error转换，否则类型不匹配 - 性能上，
std::expected是栈内对象（通常 16–32 字节），无动态分配；但频繁拷贝大值类型时，注意移动语义是否触发（建议对大对象用std::unique_ptr包装）
如何统一业务错误类型并避免模板爆炸
大型项目里，不同模块定义自己的 error 枚举或结构体很常见，但直接让 std::expected<t mymoduleerror></t> 泛滥会导致模板实例化数量激增、链接变慢、调试信息膨胀。关键不是“用 enum class”，而是收敛错误载体。
- 定义一个轻量级、POD 的公共错误码类型，例如
struct BusinessErrorCode { uint16_t code; uint8_t domain; }，避免虚函数和 std::string 成员 - 各模块通过静态函数映射：比如
MyDb::toErrorCode(DbError e)→BusinessErrorCode{.code = 42, .domain = 'DB'} - 不要为每个模块创建独立的
std::expected<t modulexerror></t>别名；统一用using Result = std::expected<t businesserrorcode>;</t>，降低实例化压力 - 调试时可通过
BusinessErrorCode::domain快速定位错误来源模块，无需依赖类型名
与异步流程（如 std::future、libuv 回调）配合的关键约束
std::expected 本身不带执行上下文，无法自动调度到某个线程或事件循环。在异步业务链中强行塞入 std::expected 返回值，容易误以为“错误被自动传递”，实际可能丢失上下文或死锁。
- 回调函数签名应为
void(std::expected<t e>)</t>，而不是std::expected<t e>(...)</t>—— 异步操作完成时才交付结果，不能提前返回 - 若使用
std::future，不要包装std::expected进去（如std::future<:expected>></:expected>），而应让 promise 的set_value/set_exception分开处理：成功走set_value，失败走set_exception并附带std::exception_ptr，再由顶层统一转为std::expected - libuv 或类似 C 风格回调中，错误码通常作为参数传入（如
void cb(int status, void* data)），此时应立刻构造std::expected<t e></t>并移入后续 handler，禁止在回调里做复杂逻辑或阻塞操作
调试期最容易忽略的 std::expected 崩溃点
崩溃往往不出现在 .value() 调用时，而出现在移动后访问——因为 std::expected 移动后，原对象状态未明确指定（C++23 标准只保证“可析构、可赋值”，不保证仍含有效值），而部分实现（如 libc++）会将移动后的 std::expected 置为无效状态，再次调用 .value() 触发断言或未定义行为。
立即学习“C++免费学习笔记（深入）”；
- 永远不要对已移动的
std::expected对象调用.value()或.error()；移动后仅可安全调用.has_value()或赋值 - 在日志或断言中打印错误时，先检查
e.has_value()，再决定取e.value()还是e.error()，别图省事写e.value_or(...)就完事 - 单元测试要覆盖“移动后访问”场景，尤其在工厂函数、管道式组合（
and_then+ lambda 捕获）中极易发生
真正难的不是写出第一个 std::expected，而是让整个团队在每层函数签名、每个日志点、每次移动操作里都保持对值状态的敬畏——它不抛异常，但会静默失效。
