c++异常：适合严重错误和资源管理场景
异常适用于程序无法继续执行的严重问题，比如内存分配失败、文件打开失败且无备选路径、逻辑前提被破坏（如空指针解引用前未检查）。它的核心优势是能自动栈展开，配合 RAII 可靠释放资源——析构函数在异常传播途中必然执行。但代价明显：启用异常会增加二进制体积，影响部分嵌入式或高性能场景；编译器需生成额外的 unwind 表；且调用方若忽略 catch，会导致程序终止，对可靠性要求极高的系统需谨慎。
建议：
- 服务端核心逻辑、桌面应用中可放心使用异常处理不可恢复错误；
- 禁用异常时（-fno-exceptions），必须同步禁用 throw/catch 和依赖异常的 STL 组件（如 std::vector::at()）；
- 不要用异常传递业务状态（如“用户不存在”），这属于预期分支，不是错误。
错误码：轻量、可控，适合系统层与跨语言接口
返回整数（如 POSIX 的 errno）、枚举或自定义错误类型（如 std::error_code），调用方必须显式检查。它零开销、确定性高、兼容 C 接口，是驱动、OS 内核、嵌入式模块的主流选择。缺点是容易被忽略（忘记 if 判断）、错误传播冗长（层层 return）、难以携带上下文信息。
建议：
- 在 ABI 稳定接口（如 DLL 导出函数、C API 封装层）中统一用错误码；
- 使用 std::error_code + std::error_condition 实现可扩展、可比较、可翻译的错误分类；
- 配合宏或辅助函数（如 TRY_CALL(f())）减少样板检查代码。
Expected（如 std::expected 或第三方库）：兼顾表达力与控制流清晰度
std::expected（C++23 标准化）将成功值与错误对象封装在一个类型中，强制调用方处理两种可能。相比异常，它不触发栈展开，性能可预测；相比错误码，它天然支持携带丰富错误信息（如结构化错误对象、堆栈快照、原始错误码），且避免了“错误被静默忽略”的风险（访问 .value() 前通常需先检查 .has_value() 或用 .and_then() 等组合子链式处理）。
建议：
- 新项目中优先考虑 std::expected 处理可恢复的、预期发生的错误（如解析失败、网络超时、配置缺失）；
- 配合 std::unexpected 和自定义错误类型，实现语义清晰的错误建模；
- 注意避免过度嵌套（如 expected），必要时用 transform() 或 and_then() 扁平化。
怎么选？看错误性质、团队习惯与部署约束
关键判断依据不是“哪个更先进”，而是：
- 错误是否允许局部处理后继续执行？→ 是 → 用 expected 或错误码；否 → 异常更自然；
- 是否需跨语言调用或运行在无异常环境？→ 是 → 排除异常，选错误码或 expected（后者需确保 ABI 兼容）；
- 团队是否已建立成熟错误码分类体系？→ 是 → 延续比切换成本更低；
- 是否需要错误上下文（如位置、输入片段、嵌套原因）？→ expected 比裸错误码更易承载。
混合使用合理：底层驱动用错误码，中间件用 expected 封装并补充上下文，上层业务逻辑对致命错误仍 throw 异常（如鉴权失败后拒绝服务）。
立即学习“C++免费学习笔记（深入）”；
