std::optional适用于语义上正常、无需错误信息的缺失场景，如哈希表未命中或JSON可选字段不存在；若需传达失败原因（如文件不存在、解析格式错误），应改用std::expected或异常。
std::optional 适合“没找到”而不是“出错了”
它只该用于语义上完全正常、不带错误信息的缺失场景。比如查哈希表没命中、读配置项字段缺失、解析 JSON 时某个可选字段不存在——这些不是程序异常，而是业务逻辑天然就允许的分支。一旦你需要告诉调用方“为什么失败”，比如 std::errc::no_such_file_or_directory 或自定义的 ParseError::InvalidFormat，std::optional 就越界了，该换 std::expected 或异常。
别用 std::optional 包裹系统调用失败或 I/O 错误
像 open()、read()、fstat() 这类 POSIX 接口，失败时 errno 携带关键上下文，直接丢进 std::nullopt 就等于把诊断线索全删了。常见误用：
- 写
std::optional<int> safe_read(int fd, void* buf, size_t n)</int>—— 无法区分是 EOF、EAGAIN 还是 EIO - 封装
getaddrinfo()返回std::optional<sockaddr_storage></sockaddr_storage>—— 调用方根本不知道是 DNS 超时还是地址族不支持
这类操作应返回 std::expected<t std::error_code></t>，让错误类型可匹配、可日志、可重试。
数学计算和解析类函数要小心定义域边界
std::optional 在这里很合适，但前提是“无定义”纯属数学事实，不涉及外部状态。例如：
立即学习“C++免费学习笔记（深入）”；
-
std::optional<double> sqrt(double x)</double>：当x 时返回 <code>std::nullopt，符合实数域定义，无需 errno -
std::optional<int> parse_int(std::string_view s)</int>：输入非法（如"abc"）就空，不关心是编码问题还是缓冲区溢出
但如果解析失败是因为磁盘读取截断（即输入数据本身被破坏），那就不再是“格式错”，而是“数据源损坏”，此时也该升格为 std::expected。
性能敏感路径中避免含非平凡类型的 optional
虽然 std::optional<int></int> 几乎零开销，但 std::optional<:string></:string> 或 std::optional<:vector>></:vector> 在频繁返回空值时，构造/析构仍会触发分支预测失败和缓存抖动。尤其在嵌入式或高频服务端热循环里：
- 每次返回
std::nullopt，对象仍需按std::string对齐填充，占用 24–32 字节（取决于平台） - 若 90% 的调用都返回空，却仍为每个空实例预留字符串内部缓冲空间，就是典型的内存浪费
这时要么改用裸指针加注释（明确生命周期），要么用 std::expected<t std::monostate></t> 避免存储冗余——但后者语义已偏移，慎选。
最常被忽略的一点：std::optional 的价值不在“能用”，而在“迫使调用方面对空状态”。只要接口契约里“无值”是合法且自洽的终点，它就站得住；一旦这个“无”背后藏着需要诊断、分类、恢复的上下文，它就已经失职了。
