std::is_convertible 是编译期类型特征，仅验证 From 能否隐式转换为 To，不保证“完全兼容”；它不检查内存布局、ABI、sizeof、对齐、虚函数表或运行时安全性。
std::is_convertible 是什么，它能验证“完全兼容”吗？
std::is_convertible<From, To> 检查的是“From 是否能隐式转换为 To”，不是类型等价、内存布局一致或 ABI 兼容。它只管表达式 static_cast<To>(std::declval<From>()) 在语法和语义上是否合法（不考虑 SFINAE 以外的约束）。所谓“完全兼容”是常见误解——它不保证 reinterpret_cast 安全、不检查对齐、不验证 sizeof 或成员偏移，更不涉及虚函数表或继承关系完整性。
典型误用场景：有人想靠它确认两个 struct 能否 memcpy 互换，或判断派生类能否安全转基类指针——这些它都管不了。
怎么写一个可靠的编译期转换合法性检查
如果目标确实是“能否隐式转”，std::is_convertible 本身已足够，但需注意几个关键点：
- 它只检测隐式转换（不含
explicit构造函数或转换运算符）；要测 explicit 转换，得手动构造表达式 +decltype+ SFINAE - 模板参数必须是完整类型；对前置声明类型（如
class A;）使用会触发硬错误，不是 SFINAE 友好 - 数组类型、函数类型、抽象类类型不能作为
To；例如std::is_convertible<int, void()>直接编译失败 - 引用类型行为特殊：
std::is_convertible<int&, const int&>为true，但std::is_convertible<int, int&>为false（无法从值绑定到非 const 左值引用）
示例：判断 std::string 是否可隐式转 const char*：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
static_assert(!std::is_convertible_v<std::string, const char*>, "std::string 不隐式转 const char*");
常见错误现象和陷阱
最常踩的坑是把 std::is_convertible 当成“安全转型断言”。比如：
- 对
std::shared_ptr<Derived>到std::shared_ptr<Base>使用它返回true，但若Base非虚析构，运行时 delete 仍 UB —— 编译期检查不捕获此问题 - 自定义类型含
operator bool()，导致std::is_convertible<T, bool>为true，但该转换可能被用于条件判断引发意外逻辑 - 在模板中直接依赖
std::is_convertible_v<A, B>做分支，却没处理A或B为void的情况（标准规定std::is_convertible<void, T>对任意T都是false）
另一个隐形陷阱：用户定义的转换函数若抛异常（C++11 后允许），std::is_convertible 仍返回 true，但实际调用时可能崩溃。
替代方案：什么时候该换别的工具
如果真正关心的是“二进制兼容”或“可 memcpy 替换”，该看：
-
std::is_trivially_copyable_v<T>和std::is_standard_layout_v<T>—— 用于判断 POD/标准布局类型 -
std::is_same_v<A, B>或std::is_base_of_v<B, A>—— 比is_convertible更精确地刻画继承关系 - 对指针转换，用
std::is_convertible_v<U*, T*>不如直接static_cast+noexcept检查（C++20 起支持std::is_nothrow_convertible）
std::is_nothrow_convertible_v<From, To>（C++20）比老版多一层保障，但它依然不管对象生命周期、虚函数调用或 RTTI 一致性。
真正难的是跨 ABI 边界或序列化场景下的“兼容性”——那已经超出类型系统能力范围，得靠协议版本、字段校验或运行时反射。编译期能做的，始终只是语法层面的一道窄门。
