std::optional解引用空值抛std::bad_optional_access异常；if(opt)是零开销安全判空；禁止链式访问和reset后直接解引用；多线程需同步，const函数中延迟初始化需mutable。
std::optional 解引用空值直接抛 std::bad_optional_access
它不是空指针解引用，也不是段错误，而是明确的 C++ 异常：调用 *opt 或 opt->member 时，若 opt.has_value() 为 false，标准库会立即抛出 std::bad_optional_access。这不是编译期检查，是运行期强制拦截——你漏判空，它就炸，不给你侥幸机会。
if (opt) 是最简、最安全、零开销的空检查写法
别写 if (opt.has_value())，也别依赖 opt.value() 的异常兜底。前者多一次函数调用（虽小但没必要），后者把流程控制交给异常，违背 std::optional 的设计本意。
-
if (opt)调用的是operator bool()，内联、无分支预测惩罚、语义直白 - 必须把解引用操作严格限制在
if (opt) { ... }作用域内，不能提前声明引用或指针变量 - 禁止在
else分支里写*opt——那地方根本没值，编译器不会拦，运行就崩
深层嵌套 optional 链式访问是高危操作
像 user.profile.avatar_url.value() 这种写法，只要 user、profile 或 avatar_url 中任意一个为空，立刻崩溃。C++ 的 std::optional 不支持空传播（no null propagation），也没有 and_then 或 map 接口。
- 正确做法是逐层显式判断：
if (user && user->profile && user->profile->avatar_url) - 更稳妥的是下沉检查点，比如封装成
std::optional<:string> get_avatar_url(const User& u)</:string>，内部做完整判空 - 如果嵌套层级超过两层，大概率说明类型建模有问题，该扁平化或换用
std::shared_ptr
reset() 后忘记检查就解引用，和一开始就空没区别
opt.reset() 会析构当前值并置空，之后状态等价于刚构造的 std::optional<t>{}</t>。常见陷阱是 reset 后直接写 *opt，尤其在条件分支或循环中容易忽略。
立即学习“C++免费学习笔记（深入）”；
- reset 前后都应视作“可能为空”状态，不能假设 reset 只是清掉旧值、新值马上就有
- reset 不等于 emplace，它不触发重建；想重置+重建，请用
opt.emplace(args...) - 多线程下
if (!opt) opt.reset(); opt.emplace(...)是未定义行为，必须用std::call_once同步
最易被忽略的一点：const 成员函数里调用 emplace() 做延迟初始化时，std::optional 和配套的 std::once_flag 都得加 mutable。少一个，编译失败；多一个，逻辑错乱。这不是语法糖，是类型系统对可变性的诚实要求。
