c++中不存在“constexpr深拷贝”——因深拷贝需动态内存分配和运行时逻辑，而constexpr仅允许字面量类型及编译期可求值操作；所有成员必须为字面量类型且构造/复制行为可在编译期完成。
constexpr 深拷贝根本不存在——先破除概念误区
C++ 标准里没有“constexpr 深拷贝”这个术语，也没有编译期执行深拷贝的机制。constexpr 函数或构造函数只能操作字面量类型（literal type），而深拷贝必然涉及动态内存分配（如 new）、运行时指针解引用、或非 trivial 的资源管理逻辑——这些全被 constexpr 上下文禁止。
常见错误现象：写了一个带 std::vector 或 std::string 成员的类，给它加 constexpr 构造函数，结果编译失败，报错类似：call to non-constexpr function 'operator new'。
关键判定准则只有一条：该类的所有成员必须是字面量类型，且所有构造/赋值/析构行为在 constexpr 上下文中可求值。
判断类是否支持 constexpr 构造/复制的四步检查法
不是看“能不能深拷”，而是看“能不能在编译期完成整个对象生命周期的初始化与值语义复制”。
- 类必须是
trivially_copyable且destructible，且满足字面量类型要求（C++17 起：有constexpr构造函数、无虚函数、无虚基类、所有非静态成员和基类都是字面量类型） - 所有非静态数据成员的类型必须自身支持
constexpr构造；例如int、std::array<int></int>可以，std::unique_ptr<int></int>不行（其构造函数非constexpr） - 若定义了
constexpr复制构造函数，它内部不能调用任何非constexpr函数（包括隐式调用的成员复制构造函数），也不能有运行时分支（如if判空指针做“深拷贝”逻辑） - C++20 起可借助
std::is_literal_type_v<t></t>（已弃用）或更可靠的std::is_trivially_copyable_v<t> && std::is_default_constructible_v<t></t></t>+ 手动验证成员，但最准的方式仍是尝试声明constexpr T x{...};并观察编译器反馈
示例：
struct Good {
int x;
constexpr Good(int a) : x(a) {} // ✅
};
constexpr Good a{42};
constexpr Good b = a; // ✅ 编译期位拷贝，等价于 memcpy
为什么 std::string / std::vector / 自定义 RAII 类一定不行
它们的“拷贝”行为本质是运行时语义：分配新内存 → 逐元素复制 → 更新管理指针。这三步在 constexpr 上下文中全部非法。
-
std::string的复制构造函数会调用allocate和construct，二者都不是constexpr - 即使你把
std::string成员换成const char*，只要它指向堆内存或需运行时计算的地址，仍无法用于constexpr上下文 - 自定义类若含
int*成员并试图在构造函数中new int{val}，直接触发error: call to non-constexpr function
性能影响其实不相关——这不是“慢不慢”的问题，而是“根本不允许发生”的硬性限制。
替代方案：用编译期友好的结构模拟“值语义”
如果目标是让类在编译期可构造、可传递、可比较（而非真做深拷贝），应彻底放弃指针和动态分配：
- 用
std::array替代std::vector，大小必须为编译期常量 - 用
std::span（C++20）或固定长度char[N]存储字符串字面量，避免所有权转移 - 所有“复制”操作实际是 trivial bit-wise copy，由编译器自动完成，不需要用户写复制构造函数
- 若需多态或运行时行为，明确划清边界：constexpr 部分只负责配置/索引/状态码等纯数据，复杂逻辑延迟到运行时处理
容易被忽略的一点：即使类满足所有 constexpr 条件，只要某个 constexpr 函数里写了 static_assert(!std::is_pointer_v<decltype>, "...");</decltype>，它依然可能因模板实例化路径不同而意外失效——真正可靠的判定永远是“让编译器试一次”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
