std::variant作为函数返回值的核心优势是强制穷尽分支处理，而非单纯替代错误码；必须用std::visit或完整std::get_if判断所有可能类型，否则易因漏处理导致运行时崩溃。
std::variant 作为函数返回值，核心优势不是“比错误码更高级”，而是能强制你面对所有可能分支——只要你用对了访问方式；否则它比裸错误码还危险。
std::holds_alternative 不能代替完整分支处理
很多人写 std::holds_alternative<int>(result)</int> 然后只处理成功路径，把错误类型（比如 std::string 或 std::error_code）晾在一边。这看起来像在检查，实际等于没检查：编译器不报错，运行时一旦进错分支就触发 std::bad_variant_access 崩溃。
- 正确做法是必须用
std::visit+ 完整 lambda 分支，或至少用std::get_if对每个可能类型做非空判断 - 如果未来给
std::variant<int std::string></int>加上第三个类型std::runtime_error，但忘了更新std::visit的 lambda，编译器会直接报错——这是唯一能靠住的防线 - 错误码（如
int返回值）没有这种编译期约束，漏判== -1就静默走错路
std::visit 是唯一安全的访问入口
用 std::get<int>(v)</int> 或 std::get(v) 访问 std::variant，本质上和裸 union 一样危险：类型不匹配就抛 std::bad_variant_access，而且这个异常无法静态推导是否会被覆盖。
-
std::visit强制你写出所有分支逻辑，编译器能验证是否穷尽（C++17 起支持if constexpr+std::is_same_v编译期分发） - 避免用
std::get_if<t>(&v)</t>后直接解引用——要先判空：if (auto p = std::get_if<int>(&v)) { use(*p); }</int> - 别把
std::visit写成单分支 lambda：std::visit([](auto&& x) { ... }, v)看似简洁，实则放弃类型区分，失去std::variant的存在意义
相比错误码，内存布局没优势，语义代价却更高
std::variant<int std::error_code></int> 和单纯返回 int 错误码相比，体积通常更大（至少多一个 tag 字节），构造/赋值开销也略高。它的价值不在性能，而在把“多态返回”这件事显式抬到类型系统里。
立即学习“C++免费学习笔记（深入）”；
- 错误码依赖文档约定：谁规定
-1是 IO 错误、-2是解析失败？没人 enforce -
std::variant把错误类型直接写进签名：std::variant<data parseerror></data>，IDE 能跳转、静态分析能追踪、重构时类型系统会报错 - 但代价是：你必须为每种错误类型定义具体类/枚举，不能图省事全塞进
std::string——否则就退化成带 tag 的 printf 错误码
std::variant 不是 std::expected 的平替
看到 std::variant<t e></t> 就以为能当错误处理用，是常见误解。它缺三样东西：std::expected 天然带有的二元语义、and_then 链式传播能力、以及编译期强制的 success/failure 路径检查。
- 写
parse() → validate() → serialize()链路时，std::expected可以一行parse().and_then(validate).and_then(serialize)；std::variant必须三层std::visit套娃，每层都要手动传 error 向下 -
std::variant允许你定义std::variant<t e1 e2 e3></t>，但这就破坏了“成功/失败”的二元契约，后续组合逻辑立刻爆炸 - 如果你真只需要 success/error 两种状态，优先用
std::expected<t e></t>；std::variant更适合“多种成功形态”场景，比如解析器返回std::variant<number string array object></number>
真正容易被忽略的是：std::variant 的安全性完全依赖访问方式。不用 std::visit 或漏写分支，它就退化成带类型擦除的 union——比原始错误码更难 debug，因为崩溃点离出错位置更远。
