构造函数中执行大量工作会导致对象状态不一致、资源泄漏、虚函数调用失效及性能下降；应将重活移至工厂函数、延迟加载或两阶段构造中。
构造函数里做大量工作会导致对象状态不一致
一旦构造函数中途抛异常，对象就处于“半构造”状态：部分成员已初始化，部分还没开始；析构函数不会被调用，已分配的资源（比如 new 出来的内存、打开的文件句柄）会直接泄漏。这不是理论风险——C++标准明确要求：构造失败时，已成功初始化的子对象会被逆序析构，但没走到初始化列表里的成员、或初始化列表中抛异常之后的成员，根本不会进入析构流程。
常见错误现象包括：
- 日志里反复出现
std::bad_alloc后程序内存持续增长 - 调试时发现某个
std::vector成员已构造，但其内部缓冲区指针为nullptr（说明vector构造成功，但后续resize()在函数体里失败） - 用 RAII 封装的资源（如自定义
FileHandle）在构造函数体里调用open()失败，但析构函数收不到通知，无法清理临时创建的锁或注册表项
委托构造函数不能绕过“函数体里做事”的陷阱
有人以为用了委托构造函数就能把逻辑“收拢到一个地方”，就安全了——错。委托只解决初始化列表重复的问题，Rectangle(double w, double h) : width(w), height(h) { /* 这里照样能写100行业务代码 */ } 依然在函数体里执行。只要逻辑写在花括号内，就逃不开异常导致的资源泄漏、状态不完整、难以测试等问题。
正确做法是把重活移出构造函数：
立即学习“C++免费学习笔记（深入）”；
- 用
static工厂函数（如make_config()）封装校验、IO、网络请求等易失败操作，返回std::optional<Config>或std::expected<Config, Error> - 把耗时计算拆成
init_cache()等延迟加载方法，在首次访问时才触发 - 对必须在构造期完成的复杂初始化，改用两阶段构造：先调轻量构造函数，再显式调
validate_and_finalize()，由调用方决定是否容忍中间态
虚函数调用在构造函数里必然失效
如果构造函数体里调了 virtual 函数，哪怕只是为了“统一日志格式”，实际调用的永远是当前正在构造的那个类的版本，不是最终派生类的重写版。比如 Base::Base() { log_start(); } 中的 log_start()，在 Derived 对象构造时仍走 Base::log_start()，因为此时 vptr 还没指向 Derived 的虚表。
这个行为不可修复，也不该绕过。它暴露的是设计问题：把本该由具体类型决定的行为，提前塞进了基类构造流程。更自然的解法是去掉构造期虚调用，改用模板参数、策略对象或工厂注册表来注入行为。
编译器无法优化构造函数体内的冗余计算
初始化列表中的表达式可能被常量折叠（如 size_(N * sizeof(int))），但函数体里的赋值、循环、条件分支基本都会原样保留。尤其当构造函数被频繁调用（如容器 resize() 触发大批对象构造），这些开销会直接放大。
典型性能雷区：
- 在构造函数里反复调用
std::regex_search()解析固定配置字符串 - 用
for循环给std::array<int, 1024>填充默认值，而不是用= {}或聚合初始化 - 调用
std::sort()对一个已知有序的内置数组排序
真正难察觉的，是那些看似无害的“小操作”堆在一起：一次 std::string 拷贝 + 一次 std::map::insert() + 一次 std::chrono::steady_clock::now() —— 它们单独看都快，合起来却让构造耗时从纳秒级跳到微秒级，且无法被编译器合并或剔除。
