std::any适用于运行时类型完全不确定的场景，如插件系统或脚本引擎返回的任意值，需显式any_cast且类型检查在运行时；std::variant适用于编译期已知有限类型集合的场景，类型安全、性能更好、支持编译期检查与统一处理。
std::any 适合运行时类型完全不确定的场景
当你根本不知道容器里将来会放什么类型，而且这个类型连编译期都不可枚举（比如插件系统动态加载的类型、脚本引擎返回的任意值），std::any 是唯一选择。它内部用类型擦除实现，能存任意可复制（或可移动）类型，但代价是每次 any_cast 都要运行时检查类型 ID 是否匹配。
- 必须显式调用
std::any_cast<t>(a)</t>才能取值，否则编译失败 - 如果
T和实际存储类型不一致，any_cast抛出std::bad_any_cast - 无默认构造、无比较操作、无访问者模式，纯靠“试 cast”驱动逻辑
- 内存开销略大（至少一个指针 + 可能的堆分配）
std::variant 适合编译期已知有限类型集合的场景
当你清楚所有可能的类型，且数量不多（比如 std::variant<int std::string double></int>），std::variant 更安全、更快、更易用。它在栈上固定大小布局，访问通过 std::visit 或 std::get<t></t>，所有类型检查都在编译期完成。
-
std::get<t>(v)</t>在T不是当前活跃类型时直接触发std::bad_variant_access -
std::visit([](auto&& x) { ... }, v)要求 lambda 必须对 variant 中每种类型都可调用，否则编译失败 - 支持
std::monostate表示“空状态”，比std::any的“未初始化”语义更明确 - 不能存引用、数组、抽象类等非对象类型（和
std::any一样）
别用 std::any 替代 std::variant 的常见错误
有人图省事，把本该是 std::variant<a b c></a> 的地方换成 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 —— 后者更推荐，只要嵌套深度和类型集可控。
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
立即学习“C++免费学习笔记（深入）”；
using ConfigValue = std::variant<int, double, std::string,
std::vector<ConfigValue>,
std::map<std::string, ConfigValue>>;
硬塞 std::any 进去看似灵活，实则放弃类型约束，后续所有访问都得靠字符串匹配或 try-catch，维护成本陡增。
真正难的是判断“类型集合是否真的不可穷举”——很多所谓“动态”场景，其实只是开发初期没想清楚边界，先用 std::variant 列出已知类型，留好扩展点，比一开始就用 std::any 更可持续。
