C++中std::optional搭配std::nullopt与返回nullptr的优劣势对比

首先纠正示例代码的拼写错误：两个函数的参数cont int value应为const int value。

Case 1（返回裸指针+nullptr）对比 Case 2（返回std::optional）的优势 #

• 兼容性更强：裸指针返回空值是C全版本支持的通用写法，不需要依赖C17才引入的std::optional特性和<optional>头文件，可以兼容所有老旧标准的项目。
• 运行开销更低：裸指针是原生类型，返回、传递、使用都是零开销，虽然std::optional的额外开销几乎可以忽略，但在高频调用的极端性能敏感场景下，裸指针的性能表现更稳定，且不需要做optional层的解包操作，可直接作为指针使用。
• 学习成本低：返回nullptr表示查询失败是C++开发者普遍熟悉的约定，不需要额外学习std::optional的API和语义，团队无需调整现有编码规范即可直接适配。

Case 1（返回裸指针+nullptr）对比 Case 2（返回std::optional）的劣势 #

• 语义存在歧义：返回nullptr无法区分「查询失败无结果」和「查询成功但存储的指针本身就是空值」两种完全不同的场景，业务逻辑复杂时很容易出现隐性错误；而std::nullopt明确表示没有查询到结果，和查询到的指针本身的取值完全独立，语义没有任何歧义。
• 安全性更低：调用方很容易遗忘检查返回值是否为空就直接解引用，引发空指针崩溃，编译器不会对这类漏检查的操作做出任何告警；而std::optional要求调用方必须显式处理空状态：要么先调用has_value()判断是否有值，要么调用value()在空状态下主动抛出异常，要么用value_or()指定缺省值，从编码层面大幅降低了空访问的风险。
• 扩展性更差：一方面，C++23之后std::optional支持and_then、transform、or_else等链式调用接口，可以大幅简化多层判空的逻辑，裸指针实现只能手写多层if判空，代码冗余度更高；另一方面，如果后续接口迭代需要返回非指针类型的查询结果，std::optional可以直接复用这套「有值/无值」的语义，而返回nullptr的方案完全无法适配非指针的返回类型，重构成本极高。

注：两个示例中出现的const_cast和两种实现方案的选择无关，仅和接口是否要返回可修改的指针有关，如果将返回值改为const SomePointer*即可去掉const_cast操作。

内容的提问来源于stack exchange，提问作者Meric Ozcan