std::optional解引用前必须检查空状态，否则运行时抛std::bad_optional_access；最安全方式是if(opt){...}，避免多线程竞态需配合mutable std::once_flag与std::call_once。
std::optional 解引用前必须检查空状态
不检查就用 *opt 或 opt->member，运行时直接抛 std::bad_optional_access。这不是编译错误，是运行期崩溃——尤其在多线程或条件分支中容易漏判。
-
if (opt)是最简明安全的检查方式，它调用operator bool()，语义清晰且无额外开销 - 禁止把解引用写在
if外部、else分支或作用域外；一旦离开if (opt) { ... }块，就不能再假设opt有值 -
opt.value()会主动检查并抛异常，但生产环境应避免依赖异常做流程控制 -
opt.has_value()可读性稍弱，且多一次函数调用，除非用于断言或日志
value_or() 适合提供轻量默认值的只读场景
当资源引用存在自然“空语义”（比如空正则不匹配、空配置对象视为默认行为），value_or() 能彻底绕过空值异常路径，但前提是默认值构造成本足够低。
- 用
static const std::regex empty_regex;这类静态对象作默认值，避免临时对象生命周期问题 - 不要传临时对象如
opt.value_or(std::regex{})，若后续代码引用返回值，可能绑定到已析构的临时量 - 该方法仅适用于只读访问；若需修改内部状态，仍得走
if (opt)+*opt路径
多线程下 if (!opt.has_value()) opt.emplace() 是危险竞态
两个线程同时进入 if 判断，都看到 !opt.has_value() 为真，接着都调用 emplace()，结果是未定义行为：可能 double-construct、内存踩踏、或静默损坏缓冲区。
- 必须搭配
mutable std::once_flag和std::call_once，初始化逻辑写在 lambda 里 -
std::call_once的 lambda 内不能抛异常；若初始化可能失败（如文件读取失败），需提前捕获并转为可观察状态（如设标志位或用std::expected） -
std::once_flag必须是类成员，不能是局部静态变量——否则每次调用都新建一个 flag，完全失效
const 成员函数里修改 optional 需要 mutable
延迟初始化常发生在 const getter 中，但 emplace() 和 std::call_once 都会修改对象状态。不加 mutable 就编译不过。
-
mutable std::optional和mutable std::once_flag是成对出现的，缺一不可 - 即使整个类设计为逻辑 const（对外不改变可见状态），内部缓存/惰性加载也需这种“逻辑可变性”
- 别试图用 const_cast 绕过——破坏 const 正确性，且无法解决
std::once_flag的修改需求
真正容易被忽略的是：std::optional 的“空”只表示“尚未构造”，不代表“构造失败”。一旦 emplace() 抛异常，optional 仍保持空状态，但你无法区分是“没试过”还是“试过但失败了”。需要失败可观测能力时，得换 std::expected 或额外状态字段。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
