c++的std::any和std::variant的适用场景有何不同？ (类型安全容器)

std::any适用于运行时类型完全不确定的场景，如插件系统或脚本引擎返回的任意值，需显式any_cast且类型检查在运行时；std::variant适用于编译期已知有限类型集合的场景，类型安全、性能更好、支持编译期检查与统一处理。

std::any 适合运行时类型完全不确定的场景

当你根本不知道容器里将来会放什么类型，而且这个类型连编译期都不可枚举（比如插件系统动态加载的类型、脚本引擎返回的任意值），std::any 是唯一选择。它内部用类型擦除实现，能存任意可复制（或可移动）类型，但代价是每次 any_cast 都要运行时检查类型 ID 是否匹配。

• 必须显式调用 std::any_cast(a) 才能取值，否则编译失败
• 如果 T 和实际存储类型不一致，any_cast 抛出 std::bad_any_cast
• 无默认构造、无比较操作、无访问者模式，纯靠“试 cast”驱动逻辑
• 内存开销略大（至少一个指针 + 可能的堆分配）

std::variant 适合编译期已知有限类型集合的场景

当你清楚所有可能的类型，且数量不多（比如 std::variant），std::variant 更安全、更快、更易用。它在栈上固定大小布局，访问通过 std::visit 或 std::get，所有类型检查都在编译期完成。

• std::get(v) 在 T 不是当前活跃类型时直接触发 std::bad_variant_access
• std::visit([](auto&& x) { ... }, v) 要求 lambda 必须对 variant 中每种

  

  类型都可调用，否则编译失败
• 支持 std::monostate 表示“空状态”，比 std::any 的“未初始化”语义更明确
• 不能存引用、数组、抽象类等非对象类型（和 std::any 一样）

别用 std::any 替代 std::variant 的常见错误

有人图省事，把本该是 std::variant 的地方换成 std::any，结果埋下隐患：

• 类型错误从编译期后移到运行期，测试覆盖不到就崩溃
• 无法对所有可能类型统一处理（比如序列化、日志打印），因为没统一接口
• std::any 不支持 == 比较，而 std::variant 只要所有备选类型都可比较，它自己就可比较
• 性能差：每次 any_cast 都有虚函数调用 + RTTI 查表，而 std::variant 的 std::visit 是纯模板展开

一个典型混合使用案例

配置解析器返回值：顶层结构是已知几种类型（int、double、std::string、std::vector、std::map），用 std::variant；但 std::map 的 value 类型又可能是任意嵌套结构，此时 map 内部 value 用 std::any 或递归 std::variant —— 后者更推荐，只要嵌套深度和类型集可控。

using ConfigValue = std::variant,
                      std::map>;

硬塞 std::any 进去看似灵活，实则放弃类型约束，后续所有访问都得靠字符串匹配或 try-catch，维护成本陡增。

真正难的是判断“类型集合是否真的不可穷举”——很多所谓“动态”场景，其实只是开发初期没想清楚边界，先用 std::variant 列出已知类型，留好扩展点，比一开始就用 std::any 更可持续。