1. 什么时候应该用 std::optional 替代指针

当你需要表示一个变量可能没有值时，可以使用std::optional代替原始指针。例如，函数返回一个可能存在也可能不存在的整数时，返回类型可以设为std::optional。调用方通过检查has_value()或直接使用value()（会抛出异常）或value_or（提供默认值）来安全访问，避免了因返回nullptr导致的未定义行为。这种用法最常见于查找、解析和配置读取等场景。与返回原始指针不同，optional 明确告知调用方“可能无值”，且不允许通过赋值 null 来伪造无效状态——你必须用 std::nullopt 或默认构造来表示无值。这从接口层面杜绝了空指针引入的歧义。在实际项目中，可以先从那些容易返回 null 或 -1 的函数入手，逐步替换为 optional，减少运行时指针检查的遗漏。

2. 安全访问的前提：先判断再取值

使用std::optional时，务必先判断是否包含值再访问。判断方法有两种：调用has_value()成员函数，或者将optional对象直接放入if条件中（它支持隐式转换为bool）。不要使用value()而不加判断，如果optional为空，value()会抛出std::bad_optional_access异常，这仍属于运行时错误，需要妥善捕获。因此，推荐的做法是将 optional 与 if 语句配合：if (opt) { use(opt.value()); } 或 if (auto val = opt.value_or(default_val)) { ... }。如果代码路径中一定会访问，且不希望在异常上消耗额外分支，也可以先检查 has_value() 再调用 value()，但 valueless_by_exception() 仅在极少情况下需要关注。你可以编译时加上 -Wno-return-type 等警告，但更重要的是在 Code Review 中强制检查 optional 的访问路径。

3. 常见错误：混淆空状态与无效值

一个常见错误是混淆了std::optional的默认构造与值构造。默认构造的optional不含值，而用std::nullopt或{}初始化同样不含值。如果想表示“无效值”，不要用0或-1这类特殊值，而应使用optional。另外，不要将std::optional用于动态分配，它的语义是值语义，内部存储的是对象本身，而不是指针。因此，当你用 std::optional opt; 时，opt 内部不包含值，不是整数0。如果你误用 opt.value_or(0) 并认为 opt 一定包含有效值，就可能漏掉对空状态的判断。另一种常见情况是在类成员中使用 optional 时，忘记在构造函数初始化列表中显式初始化，导致成员默认含值（如果类型有默认构造）或不含值（如果没有默认构造）。建议在声明时直接用 = std::nullopt 或 = {} 赋予明确的空状态。

4. 函数参数与可选语义的传达

将 std::optional 作为函数参数，可以更清晰地表达“传入的值可选”。例如，void process(std::optional option) 内部通过 if(option) 检查是否有值。调用方可以直接传空 optional（{}）或某个值。这避免了函数内部对空指针的检查，也防止了调用方意外传入 nullptr 导致的崩溃。相比传递指针，optional 的参数不会产生 null 的歧义——指针可能被传 nullptr，也可能指向有效内存，而 optional 只能通过构造时的 {value} 或 std::nullopt 来区分。不过要注意，optional 参数会复制值，对于大对象代价较高，可以考虑传 const std::optional& 或 std::optional&&（移动语义）。如果对象不可复制且不可移动，则只能传指针。在接口设计时，可以先从基本类型和简单结构开始使用 optional 参数，对复杂类型再评估复制开销。

5. 风险边界：性能与引用的限制

std::optional 并不是完全零开销的：它会占用至少一个额外的字节来标记是否有值。对于频繁使用的路径，这可能会导致缓存压力。在性能敏感代码中，应评估 optional 的开销。此外，不要用 optional 包装引用类型——std::optional 是不合法的。如果你需要可选引用，考虑使用原始指针或 std::reference_wrapper 配合 optional。在嵌入式或实时系统中，optional 的额外存储和对齐可能破坏布局，建议用静态分析工具（如 Valgrind 的 callgrind）或 perf 来测量热点。如果发现 optional 成为瓶颈，可以退而使用自定义的 bool + 值分离方案，但必须保证所有对值的访问都受标志位保护。总之，optional 是安全性的提升，但不是万能灵药，需要在项目具体环境中测试后再决定是否大范围应用。