std::optional 应仅用于可能无返回值的场景，如查找、解析、IO操作；避免用于必然有结果的操作，因其带来额外开销与心智负担，且空值不等于错误，需按业务语义谨慎处理。
std::optional 该在什么函数里用？
只在「可能无返回值」的场景用，比如查找、解析、IO操作。别用在明明总会返回值的函数上——那不是优雅，是画蛇添足。
常见错误现象：std::optional<int> get_value() { return 42; }</int>，调用方还得写 if (auto v = get_value()) { ... }，徒增判断开销和心智负担。
- 适合：配置项未设置时、哈希表查不到键、JSON字段缺失、文件读取失败但不想抛异常
- 不适合：加法函数、字符串长度计算、容器 size() 这类必然有定义结果的操作
- 性能影响：
std::optional有非空判断开销（哪怕只是检查一个布尔位），且对象需满足可移动；若内部类型很大，复制/移动成本也得算进去
怎么安全地解包 std::optional？
别直接访问 value()——它会在空值时抛 std::bad_optional_access，这和裸指针解引用一样危险。
正确做法是先检查再取值，或者用更紧凑的模式匹配式写法：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 推荐：用
if (auto opt = maybe_int()) { int x = *opt; ... }，简洁且编译器能优化掉冗余判断 - 备选：用
value_or(default_val)，但注意default_val会**总是构造**，哪怕optional有值；对昂贵对象要小心 - 陷阱：
operator->和operator*都不检查空值，一旦为空就是未定义行为
返回 std::optional 时要注意哪些隐式转换？
C++17 起，std::optional 支持从 T 隐式构造，但这个特性容易引发歧义。
比如你写了 return nullptr; 在返回 std::optional<:string></:string> 的函数里，它会悄悄转成空 optional；但换成 return 0; 返回 std::optional<int></int> 就会变成 optional{0}，不是空的。
- 明确意图：想返回空就写
return std::nullopt;，别依赖隐式转换 - 避免歧义：不要返回字面量
0、false、nullptr等，除非你确认类型匹配且语义清晰 - 兼容性：C++17 是最低要求；GCC 7+、Clang 5+、MSVC 2017 及以上才完整支持
和异常、指针、bool+out参数比，选哪个？
不是“越新越好”，而是看错误是否属于**预期中的正常分支**。比如解析用户输入时字段缺失，就是典型 optional 场景；而内存分配失败，就该让 new 抛 std::bad_alloc。
- vs 异常：optional 更轻量，无栈展开开销，适合高频、低代价的“不存在”情况；异常更适合真正意外的错误
- vs 原始指针：optional 不需要 caller 记得判空或管理生命周期，也不会悬空；但不能像指针那样用于多态或间接修改
- vs bool + out 参数：optional 更具表达力，调用方不用预分配变量，链式调用也更自然（如
f().and_then(g).value_or(-1)）
最容易被忽略的是：optional 的「空」状态不等于「错误」，它只是表示「值不存在」。如果业务逻辑里“空”意味着需要告警、重试或 fallback 处理，那就别把它当成静默吞掉的兜底方案。
