std::optional 应用于需显式表达“有或无”语义的场景，如函数返回可能缺失的结果、结构体中可选配置项；避免用于参数模拟、 trivial 类型包装及与 boost::optional 混用。
std::optional 该在哪些地方替代 raw pointer 或 bool + value？
用 std::optional 的核心目的不是“看起来更现代”，而是让空值语义显式化、类型安全化。它适合替代那些本该“有或没有”但你又不想用 nullptr、-1、"" 这类魔法值的场景——比如函数返回可能缺失的查找结果、配置项解析时字段可选、API 响应中 nullable 字段的建模。
常见错误是把它当 std::unique_ptr 用（比如存大对象还反复拷贝），或者在明明能用引用/值语义的地方硬套 optional（徒增开销和判断负担）。
- ✅ 推荐：函数返回“可能无结果”的计算值，如
std::optional<int> find_first_even(const std::vector<int>&)</int></int> - ✅ 推荐：结构体中表示“可选配置项”，如
struct Config { std::optional<:string> log_path; };</:string> - ❌ 避免：参数传入
const std::optional<t>&</t>来模拟“可选参数”——直接用函数重载或默认参数更清晰 - ❌ 避免：对 trivial 类型（如
int）过度包装，std::optional<int></int>比int多 1 字节（通常对齐后占 8 字节），且每次访问都要检查has_value()
访问值前必须检查吗？怎么写才不容易漏判？
不检查就调用 value() 或解引用 *opt，行为是未定义的（UB），运行时崩溃都算好的，更可能是静默数据错乱。C++17 没强制编译期检查，所以得靠写法习惯防住。
最稳妥的是用 if (opt.has_value()) 或 C++17 起支持的结构化绑定（配合 std::optional 的隐式布尔转换）：
立即学习“C++免费学习笔记（深入）”；
if (auto opt_val = compute(); opt_val) {
use(*opt_val); // 此时 *opt_val 安全
}
别依赖 operator bool() 写成 if (opt) 就完事——容易让人忽略它其实是个“存在性判断”，后续仍可能误写 opt.value()。
- ⚠️ 危险写法：
return opt.value();—— 无任何检查，CI 都拦不住 - ✅ 推荐写法：
return opt.value_or(42);（提供兜底值） - ✅ 更明确写法：
return opt ? *opt : fallback;（显式分支，逻辑一目了然） - ? 提示：Clang-Tidy 有
cppcoreguidelines-avoid-magic-numbers和cert-dcl50-cpp可辅助发现裸value()调用
std::optional 和 T& / const T& 传参时性能与语义差异
std::optional 是值语义类型，拷贝构造会触发内部 T 的拷贝（若 T 不可移动，则退化为拷贝）。传参时若只是想“读一个可能为空的值”，用 const std::optional<t>&</t>；但如果函数逻辑本质是“消费这个值”，且 T 较大，考虑改用 std::optional<t>&&</t> 并 move 出内容。
对比引用传参：const T& 无法表达“空”的概念，你得额外传一个 bool is_valid，或者约定用某个特殊值（比如 std::numeric_limits<int>::min()</int>），这破坏了接口契约。
- ❌ 错误假设：
std::optional<:string> s = get_string();</:string>然后传s给函数——如果s有值且std::string很长，这里发生了完整拷贝 - ✅ 更高效：
void process(const std::optional<:string>& s)</:string>，只传引用，不触发拷贝 - ✅ 若需转移所有权：
void consume(std::optional<:string>&& s) { auto str = std::move(*s); ... }</:string> - ⚠️ 注意：
std::optional的operator=对于已含值的对象，会先析构旧值再构造新值，比原生赋值多一次开销
和 boost::optional 或第三方 optional 实现混用会出什么问题？
标准 std::optional 和 boost::optional 之间**没有隐式转换**，也不能直接比较（==、!=），连 std::hash 特化都不通用。项目里如果既有旧 boost 代码又有新 C++17 代码，很容易在接口边界出现编译失败或静默逻辑错误。
典型现象：函数声明用 boost::optional<int></int>，调用方传 std::optional<int>{42}</int>，编译器报 “no known conversion”；或者两个 optional 都为空，但 boost::optional<int>() == std::optional<int>()</int></int> 根本不成立（语法错误）。
- ✅ 迁移策略：统一 typedef，例如
using optional_int = std::optional<int>;</int>，逐步替换头文件和 using 声明 - ✅ 临时桥接：写显式构造函数或转换函数，如
std::optional<t>(boost::optional<t> b)</t></t>，但别放在公共头里污染命名空间 - ⚠️ 高危操作：用宏 #define optional std::optional —— 会破坏所有依赖 boost::optional 的第三方库
- ? 补充：MSVC 2017+、GCC 7.1+、Clang 4.0+ 对
std::optional支持完整，但早期版本（如 GCC 6）只有实验性实现，constexpr支持不全，慎用在模板元编程中
真正难的不是怎么写 std::optional，而是判断某个变量“到底该不该是 optional”——它强迫你直面设计里那些被模糊处理的空状态。一旦选错，后面全是补丁。
