std::variant不能直接替代虚函数，而是通过std::visit在编译期实现类型安全的穷尽分支处理；适用于有限、固定类型的场景（如协议消息、ast），不支持运行时扩展。
std::variant 不能直接替代虚函数，但能实现无运行时开销的类型安全分支
虚函数靠 vtable 实现动态分发，std::variant 是编译期确定类型的值容器，它本身不提供多态行为——真正起作用的是 std::visit 配合访问者（visitor）。你不是“替换虚函数”，而是在已知有限类型集合的前提下，把「运行时类型判断 + 分发」变成「编译期类型枚举 + 访问器匹配」。
典型适用场景：消息处理（如网络协议中几种固定包类型）、AST 节点遍历、状态机中的有限状态值。不适合需要运行时扩展类型（比如插件系统）的场景。
-
std::variant存储的是值，不是指针或引用，大对象要小心拷贝开销；必要时用std::variant<:unique_ptr>, std::unique_ptr<b>></b></:unique_ptr> - 所有备选类型必须满足可析构、可复制/移动，且不能是抽象类（因为要实例化）
- 访问器如果没覆盖全部类型，编译失败（c++17 起默认行为），这是安全优势，也是常见报错源头：
Error: no matching function for call to 'visit'
std::visit 的访问器写法：Lambda 比重载函数对象更直观，但要注意返回类型一致性
最简方式是传一个泛型 lambda，但必须确保所有分支返回相同类型，否则编译不过。编译器不会自动推导“最大公因类型”，而是要求每个 operator() 调用路径返回一致的 decltype。
auto result = std::visit([](const auto& v) -> int { if constexpr (std::is_same_v<std::decay_t<decltype(v)>, A>) { return v.x; } else if constexpr (std::is_same_v<std::decay_t<decltype(v)>, B>) { return v.y * 2; } else { return -1; // 必须有兜底，且类型一致 } }, var);- 用
if constexpr是关键：它在编译期丢弃不匹配分支，避免对B调用A里不存在的成员 - 不要写成多个独立 lambda（
std::visit([](A){}, [](B){}, var)），C++17 不支持这种语法，会触发 SFINAE 失败或编译错误 - 若需复用访问逻辑，定义结构体并重载
operator()，但记得显式声明所有重载，漏一个就编译失败
std::holds_alternative 和 std::get 的误用：它们破坏了 visit 的类型安全初衷
有人先用 std::holds_alternative<a>(var)</a> 判断，再用 std::get<a>(var)</a> 取值——这看似直觉，实则绕过了 std::visit 提供的穷尽性检查，也失去了编译期类型路由优势。
立即学习“C++免费学习笔记（深入）”；
- 一旦新增类型 C，
holds_alternative判断和get调用都不会报错，但逻辑可能漏处理，变成静默缺陷 -
std::get<a>(var)</a>在运行时抛std::bad_variant_access，而std::visit把错误提前到编译期 - 只有调试或日志等非核心路径才考虑
std::get_if（它返回指针，安全）；生产逻辑一律走std::visit
性能与 ABI 兼容性：variant 的 size 和 alignof 可能比预期大，跨 DLL 边界要小心
std::variant 的内存布局由最大备选类型 + 对齐要求决定，还包含内部 type-index 字段（通常 1–8 字节）。例如 std::variant<int std::String std::vector>></int> 即使只存 int，也可能占 48 字节（取决于标准库实现）。
- 频繁构造/赋值小 variant（如
std::variant<bool int double></bool>）没问题；含std::string等大对象时，注意移动语义是否被正确触发 - 不同编译器或 STL 版本对
std::variant内部字段排布可能不同，跨 DLL 或 SO 导出含std::variant的结构体极易 ABI 不兼容 - 调试时看
var.index()是最直接的方式，但别在热路径里用——它只是读一个字节，但破坏了内联和预测，不如让visit去做
实际最难的不是语法，是设计阶段就想清楚：这个类型集合真的固定吗？有没有可能未来加第 5 种类型？如果答案不确定，硬上 std::variant 只会让后续扩展成本更高。