value_or的默认值是立即求值而非懒加载，即使optional有值也会执行实参函数；适合轻量无副作用默认值，不应用于昂贵操作或需区分空/零语义的场景。
value_or 的默认值是立即求值的，不是懒加载
很多人以为 opt.value_or(expensive_func()) 只在 opt 为空时才调用 expensive_func()，其实不然：C++ 中函数调用实参在进入函数前就完成求值。哪怕 opt 已经有值，expensive_func() 也会执行一次。
- 这会导致不必要的开销，比如打开文件、查数据库、构造大对象
- 如果
expensive_func()有副作用（如修改全局状态、发日志），行为会和预期不符 - 正确做法是显式分支：
opt ? *opt : expensive_func()或opt.has_value() ? opt.value() : expensive_func()
value_or 适合轻量、无副作用的默认值
value_or 真正发挥价值的场景，是默认值本身廉价且纯（比如字面量、简单构造、POD 类型初始化）。
-
port.value_or(8080)安全高效 —— 整数字面量无开销 -
name.value_or("Unknown")合理 —— 字符串字面量构造std::string成本可控 - 但
config.value_or(load_default_config_from_disk())就危险 —— 即使配置已存在，磁盘 I/O 仍会发生
别把 value_or 当成空值兜底的万能写法
当业务逻辑需要区分“有值但为零”和“根本没值”时，value_or 会模糊语义。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 例如
std::optional<int> user_id</int>，user_id.value_or(0)把 “未登录” 和 “用户 ID 确实是 0” 混为一谈 - 此时应保留
optional类型，用if (user_id)或user_id.has_value()显式分支处理 - 强行转成非 optional 类型，等于主动放弃类型系统对空状态的约束力
注意 value_or 返回的是值，不是 optional 引用
value_or 返回的是 T 类型（即模板参数类型），不是 std::optional<t></t>。这意味着它无法链式调用 optional 方法，也不能再判空。
立即学习“C++免费学习笔记（深入）”；
- 错误写法：
opt.value_or(42).has_value()——int没有has_value() - 若需后续继续 optional 操作，应保持类型不变：
opt ? opt : std::optional<int>{42}</int> - 或者用更清晰的表达：
opt.value_or(42)仅用于最终取值，不用于中间流程
