C++核心机制与设计原则深度解析

1. C++面试核心要点深度解析

作为一名在C++领域摸爬滚打多年的开发者，我深知大厂面试对C++核心机制的考察深度。本文将带你深入剖析10个高频面试题，从内存管理底层到面向对象核心机制，每个问题都会给出标准回答、加分技巧和避坑指南。

2. 友元机制详解与应用场景

2.1 友元函数与友元类本质

友元机制是C++中一个独特而强大的特性，它允许特定的外部函数或类访问某个类的私有成员。这种设计看似打破了封装性原则，但在特定场景下却非常必要。

友元函数本质上是一个非成员函数，但它被授予了访问类私有成员的权限。它的声明方式是在类定义中使用friend关键字：

cpp复制class MyClass {
private:
    int secret;
public:
    friend void printSecret(const MyClass& obj);
};

void printSecret(const MyClass& obj) {
    std::cout << obj.secret;  // 可以访问私有成员
}

友元类则是将整个类声明为友元，使得该类的所有成员函数都能访问声明友元的类的私有成员：

cpp复制class Helper {
public:
    void accessPrivate(MyClass& obj) {
        obj.secret = 42;  // 可以访问MyClass的私有成员
    }
};

class MyClass {
private:
    int secret;
    friend class Helper;  // 声明友元类
};

2.2 友元的典型应用场景

在实际工程中，友元机制有几个经典的应用场景：

1. 运算符重载：特别是流操作符重载

cpp复制std::ostream& operator<<(std::ostream& os, const MyClass& obj) {
    os << obj.secret;  // 需要访问私有成员
    return os;
}

2. 工厂模式：工厂类需要访问产品类的私有构造函数

cpp复制class Product {
private:
    Product() {}  // 私有构造函数
    friend class ProductFactory;
};

3. 单元测试：测试类需要访问被测类的私有成员进行白盒测试

cpp复制class TestMyClass {
    // 测试代码需要访问MyClass的私有成员
    friend class TestMyClass;
};

4. 紧密协作的类：如容器类和迭代器类

cpp复制class List {
private:
    Node* head;
    friend class ListIterator;
};

2.3 使用友元的注意事项

虽然友元很有用，但使用时需要注意以下几点：

1. 破坏封装性：友元直接访问私有成员，破坏了类的封装，应该谨慎使用
2. 关系不传递：A是B的友元，B是C的友元，不意味着A是C的友元
3. 关系不继承：基类的友元不是派生类的友元
4. 最小化原则：只授予必要的访问权限，优先考虑通过公共接口暴露功能

在实际项目中，我曾遇到一个场景：需要实现一个高性能的数学库，其中矩阵类和向量类需要频繁交互。为了减少接口调用的开销，我将它们互为友元类，这样可以直接访问内部数据实现高效运算，同时对外保持简洁的接口。

3. SOLID设计原则实战解析

3.1 单一职责原则(SRP)

单一职责原则是SOLID中最基础也最重要的原则。它要求一个类应该只有一个引起它变化的原因。换句话说，一个类应该只负责一件事情。

违反SRP的例子：

cpp复制class UserManager {
public:
    void addUser(User user);
    void deleteUser(int id);
    void logActivity(string message);  // 日志功能不属于用户管理
    void connectDatabase();  // 数据库连接也不属于这里
};

遵循SRP的改进：

cpp复制class UserManager {
public:
    void addUser(User user);
    void deleteUser(int id);
};

class Logger {
public:
    void log(string message);
};

class DatabaseConnector {
public:
    void connect();
};

3.2 开闭原则(OCP)

开闭原则指出软件实体应该对扩展开放，对修改关闭。这意味着我们应该通过添加新代码来扩展功能，而不是修改现有代码。

违反OCP的例子：

cpp复制class Shape {
    enum Type { CIRCLE, SQUARE } type;
    // ...
};

void drawShape(const Shape& shape) {
    switch(shape.type) {
        case CIRCLE: /* 画圆 */ break;
        case SQUARE: /* 画方 */ break;
        // 添加新形状需要修改此函数
    }
}

遵循OCP的改进：

cpp复制class Shape {
public:
    virtual void draw() const = 0;
};

class Circle : public Shape {
public:
    void draw() const override { /* 画圆 */ }
};

class Square : public Shape {
public:
    void draw() const override { /* 画方 */ }
};

// 添加新形状只需继承Shape，无需修改现有代码

3.3 里氏替换原则(LSP)

里氏替换原则要求派生类必须能够替换它们的基类而不影响程序的正确性。这实际上是多态性的严格定义。

违反LSP的经典例子：

cpp复制class Rectangle {
protected:
    int width, height;
public:
    virtual void setWidth(int w) { width = w; }
    virtual void setHeight(int h) { height = h; }
    int area() const { return width * height; }
};

class Square : public Rectangle {
public:
    void setWidth(int w) override { 
        width = height = w;  // 正方形设置宽高必须相同
    }
    void setHeight(int h) override {
        width = height = h;
    }
};

void testArea(Rectangle& r) {
    r.setWidth(5);
    r.setHeight(4);
    assert(r.area() == 20);  // 对于Square会失败
}

3.4 接口隔离原则(ISP)

接口隔离原则要求客户端不应该被迫依赖它们不使用的接口。我们应该将庞大的接口拆分为更小、更具体的接口。

违反ISP的例子：

cpp复制class IWorker {
public:
    virtual void work() = 0;
    virtual void eat() = 0;  // 不是所有工人都需要实现这个方法
};

class Engineer : public IWorker {
    void work() override { /* 工程师工作 */ }
    void eat() override { /* 工程师吃饭 */ }
};

class Robot : public IWorker {
    void work() override { /* 机器人工作 */ }
    void eat() override { /* 机器人不需要吃饭！ */ }
};

遵循ISP的改进：

cpp复制class IWorker {
public:
    virtual void work() = 0;
};

class IEater {
public:
    virtual void eat() = 0;
};

class Engineer : public IWorker, public IEater {
    // 实现两个接口
};

class Robot : public IWorker {
    // 只需要实现工作接口
};

3.5 依赖倒置原则(DIP)

依赖倒置原则指出高层模块不应该依赖低层模块，两者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。

违反DIP的例子：

cpp复制class LightBulb {
public:
    void turnOn();
    void turnOff();
};

class Switch {
private:
    LightBulb bulb;
public:
    void operate() {
        // 直接依赖具体实现
    }
};

遵循DIP的改进：

cpp复制class Switchable {
public:
    virtual void turnOn() = 0;
    virtual void turnOff() = 0;
};

class LightBulb : public Switchable {
    // 实现接口
};

class Switch {
private:
    Switchable& device;
public:
    Switch(Switchable& dev) : device(dev) {}
    void operate() {
        // 通过抽象接口操作
    }
};

在我的一个项目中，我们使用DIP原则设计了一个插件系统。主程序只依赖抽象的插件接口，各种插件实现这个接口并注册到系统中。这样添加新功能时只需要开发新插件，完全不需要修改主程序代码，极大地提高了系统的可扩展性。

4. C++程序执行全流程剖析

4.1 预处理阶段详解

预处理是C++编译过程的第一步，由预处理器执行。主要处理以下内容：

1. 文件包含：#include指令将头文件内容插入到源文件中
2. 宏展开：处理#define定义的宏
3. 条件编译：根据#if、#ifdef等条件决定包含哪些代码
4. 其他指令：如#pragma、#line等

预处理后的文件通常以.i为扩展名。可以使用g++ -E命令查看预处理结果：

bash复制g++ -E main.cpp -o main.i

4.2 编译阶段深度解析

编译器将预处理后的代码转换为汇编代码，主要完成以下工作：

1. 词法分析：将源代码分解为token
2. 语法分析：根据语法规则构建抽象语法树(AST)
3. 语义分析：检查类型、声明等语义规则
4. 中间代码生成：生成与机器无关的中间表示
5. 优化：进行各种优化如常量传播、死代码消除等
6. 代码生成：生成目标机器的汇编代码

编译后的汇编文件通常以.s为扩展名。可以使用g++ -S命令生成汇编代码：

bash复制g++ -S main.cpp -o main.s

4.3 汇编与链接过程

汇编器将汇编代码转换为机器码，生成目标文件（.o或.obj）。目标文件包含：

1. 机器指令
2. 数据段
3. 符号表（函数和变量名）
4. 重定位信息

链接器将多个目标文件和库文件合并，解析符号引用，生成可执行文件。链接分为：

1. 静态链接：在编译时将库代码复制到可执行文件中

   • 优点：运行时不需要依赖库文件
   • 缺点：可执行文件体积大，库更新需要重新编译

2. 动态链接：在运行时加载共享库（.so或.dll）

   • 优点：节省空间，库可独立更新
   • 缺点：运行时需要库文件存在

可以使用g++ -c命令只编译不链接：

bash复制g++ -c main.cpp -o main.o

4.4 加载与执行机制

操作系统加载可执行文件时，会进行以下操作：

1. 创建进程地址空间
2. 将程序段和数据段映射到内存
3. 初始化堆栈
4. 设置程序计数器(PC)指向入口点（通常是_start）
5. 动态链接器加载所需的共享库
6. 调用main函数开始执行

程序运行时，内存布局通常包括：

1. 代码段(text)：存放可执行指令
2. 数据段(data)：存放已初始化的全局和静态变量
3. BSS段：存放未初始化的全局和静态变量
4. 堆(heap)：动态分配的内存
5. 栈(stack)：函数调用时的局部变量和返回地址

理解整个编译执行流程对于调试复杂问题非常有帮助。我曾经遇到一个难以复现的崩溃问题，通过分析预处理后的代码和生成的汇编，最终发现是一个宏定义在特定条件下导致了未定义行为。

5. malloc底层实现深度揭秘

5.1 ptmalloc的核心设计

ptmalloc是glibc默认的内存分配器，它的设计考虑了通用性和多线程支持。主要特点包括：

1. 小块内存管理：

   • 使用"chunk"作为基本分配单元
   • 空闲chunk通过双向链表连接
   • 根据大小分类到不同的bins中

2. 大块内存处理：

   • 直接使用mmap系统调用分配
   • 避免污染主堆区
   • 释放时直接munmap

3. 多线程支持：

   • 每个线程有自己的arena
   • 减少锁竞争
   • 线程局部缓存(tcache)加速分配

5.2 内存分配算法细节

ptmalloc使用多种策略管理不同大小的内存块：

1. fast bins：

   • 存放小尺寸(通常≤80字节)的空闲chunk
   • 单链表结构，LIFO顺序
   • 不合并相邻空闲块以减少碎片

2. small bins：

   • 存放中等大小的空闲chunk
   • 62个bin，每个bin管理固定大小的chunk
   • 双向链表结构，FIFO顺序

3. large bins：

   • 存放较大的空闲chunk
   • 63个bin，每个bin管理一个大小范围的chunk
   • 按大小排序便于最佳匹配

4. unsorted bin：

   • 存放刚释放的chunk
   • 作为分配和合并的缓冲区

5.3 高级内存管理技术

现代内存分配器采用多种技术提高性能和减少碎片：

1. slab分配：

   • 为常用对象大小预分配内存
   • 减少分配开销
   • 提高缓存局部性

2. 线程局部存储：

   • 每个线程维护自己的空闲列表
   • 避免锁竞争
   • tcache在ptmalloc中的应用

3. 惰性合并：

   • 不立即合并相邻空闲块
   • 减少合并开销
   • 在必要时才合并

4. 预读和预取：

   • 预测内存使用模式
   • 预先分配内存
   • 减少分配延迟

5.4 主流分配器对比

除了ptmalloc，还有几个著名的高性能内存分配器：

1. jemalloc (Facebook)：

   • 基于arena和size class的设计
   • 优秀的碎片控制
   • 适合多线程高并发场景

2. tcmalloc (Google)：

   • 线程本地缓存
   • 中央堆管理大对象
   • 采样内存分析工具

3. mimalloc (Microsoft)：

   • 简洁高效的设计
   • 低延迟
   • 安全导向的特性

在我参与的一个高性能服务器项目中，我们将默认的ptmalloc替换为jemalloc，内存分配延迟降低了约30%，在高并发场景下效果尤为明显。但需要注意的是，不同分配器在不同工作负载下表现各异，选择前应该进行充分的基准测试。

6. 面向对象与面向过程编程范式对比

6.1 核心思想差异

面向对象(OOP)和面向过程(POP)是两种截然不同的编程范式：

1. 数据组织方式：

   • OOP将数据和方法绑定在对象中
   • POP将数据和方法分离

2. 程序结构：

   • OOP以对象为中心组织代码
   • POP以算法过程为中心

3. 抽象层次：

   • OOP强调现实世界的抽象
   • POP强调问题求解步骤

6.2 典型特性对比

6.3 适用场景分析

1. 适合OOP的场景：

   • 大型复杂系统开发
   • GUI应用程序
   • 需要高度模块化的项目
   • 需求可能频繁变化的系统

2. 适合POP的场景：

   • 性能关键的底层代码
   • 数学计算和算法实现
   • 嵌入式系统开发
   • 简单的脚本和工具

6.4 实际项目中的取舍

在实际项目中，纯OOP或纯POP都很少见，通常是混合使用：

1. 底层使用POP：

   • 操作系统内核
   • 设备驱动
   • 高性能数学库

2. 高层使用OOP：

   • 业务逻辑
   • 用户界面
   • 系统架构

3. 混合模式：

   • C++允许两种范式混合
   • 核心算法用POP实现
   • 接口和架构用OOP设计

我曾经开发过一个图像处理库，核心算法使用面向过程的方式实现以获得最佳性能，而对外接口则采用面向对象设计，提供更友好的API和扩展能力。这种混合方式既保证了性能，又提供了良好的抽象和封装。

7. 左值与右值深度解析

7.1 基本概念与区别

左值(lvalue)和右值(rvalue)是C++中表达式的两种基本分类：

1. 左值(lvalue)：

   • 表示一个具有持久状态的对象
   • 有明确的存储位置（内存地址）
   • 可以出现在赋值语句的左侧
   • 例子：变量名、返回左值引用的函数调用

2. 右值(rvalue)：

   • 表示临时的、短暂的值
   • 没有持久的存储位置
   • 不能出现在赋值语句的左侧
   • 例子：字面量、临时对象、返回非引用类型的函数调用

7.2 C++11的扩展分类

C++11引入了更精细的值类别划分：

1. 纯右值(prvalue)：

   • 传统的右值概念
   • 没有名称的临时对象
   • 例子：42, true, 函数返回的非引用类型

2. 亡值(xvalue)：

   • "将亡"的值（expiring value）
   • 可以被移动的资源
   • 例子：std::move返回的值

3. 广义右值：

   • 包括纯右值和亡值
   • 对应于右值引用(T&&)可以绑定的值

7.3 右值引用与移动语义

右值引用(&&)是C++11引入的重要特性，它支持移动语义：

1. 移动构造函数：

cpp复制class MyString {
public:
    // 移动构造函数
    MyString(MyString&& other) noexcept 
        : data(other.data), size(other.size) {
        other.data = nullptr;  // 转移资源所有权
        other.size = 0;
    }
private:
    char* data;
    size_t size;
};

2. 移动赋值运算符：

cpp复制MyString& operator=(MyString&& other) noexcept {
    if (this != &other) {
        delete[] data;  // 释放现有资源
        data = other.data;  // 接管资源
        size = other.size;
        other.data = nullptr;
        other.size = 0;
    }
    return *this;
}

3. 完美转发：

cpp复制template<typename T>
void wrapper(T&& arg) {
    // 保持arg的值类别（左值/右值）
    func(std::forward<T>(arg));
}

7.4 实际应用与性能优化

移动语义可以显著提升性能的几个场景：

1. 容器操作：

   • vector的push_back使用移动语义避免拷贝
   • 插入元素时移动临时对象

2. 返回值优化：

   • 编译器可以更高效地处理返回临时对象
   • 结合NRVO（命名返回值优化）

3. 资源管理类：

   • 文件句柄
   • 网络连接
   • 锁等RAII对象

在我的一个项目中，我们有一个大型矩阵类，实现移动语义后，矩阵作为函数返回值或临时对象的性能提升了近5倍。特别是在算法组合使用时，避免了大量不必要的深拷贝。

8. 虚函数机制全面剖析

8.1 虚函数表(vtable)原理

虚函数是实现运行时多态的关键机制，其核心是通过虚函数表实现动态绑定：

1. vtable结构：

   • 每个包含虚函数的类有一个vtable
   • vtable存储该类所有虚函数的指针
   • 编译器在编译时生成vtable

2. vptr机制：

   • 每个对象包含一个隐藏的vptr指针
   • vptr指向对应类的vtable
   • 构造函数初始化vptr

3. 调用过程：

   • 通过对象的vptr找到vtable
   • 从vtable中获取函数指针
   • 间接调用函数

8.2 虚函数调用开销分析

虚函数调用相比普通函数调用有一定的性能开销：

1. 间接调用开销：

   • 需要额外的指针解引用
   • 无法内联优化
   • 现代CPU对此有较好优化

2. 缓存影响：

   • vtable可能不在缓存中
   • 导致cache miss
   • 分支预测可能失败

3. 对象大小增加：

   • 每个对象需要存储vptr
   • 对于小对象比例显著

8.3 虚函数使用最佳实践

合理使用虚函数的几个建议：

1. 设计考虑：

   • 仅在需要运行时多态时使用虚函数
   • 避免过度设计
   • 考虑性能敏感路径

2. 性能优化：

   • 减少虚函数调用频率
   • 批量处理虚函数调用
   • 考虑模板替代方案

3. 实现细节：

   • 将析构函数声明为virtual（如果类可能被继承）
   • 考虑将不打算被重写的函数声明为final
   • 避免在构造函数中调用虚函数

8.4 替代方案与模式

在某些场景下可以考虑替代虚函数的设计：

1. CRTP（奇异递归模板模式）：

cpp复制template <typename Derived>
class Base {
public:
    void interface() {
        static_cast<Derived*>(this)->implementation();
    }
};

class Derived : public Base<Derived> {
public:
    void implementation() {
        // 具体实现
    }
};

2. 策略模式：

cpp复制class Strategy {
public:
    virtual void execute() = 0;
};

class Context {
    std::unique_ptr<Strategy> strategy;
public:
    void setStrategy(std::unique_ptr<Strategy> s) {
        strategy = std::move(s);
    }
    void executeStrategy() {
        strategy->execute();
    }
};

3. 类型擦除：

cpp复制class AnyCallable {
    struct Concept {
        virtual ~Concept() = default;
        virtual void invoke() = 0;
    };
    
    template<typename T>
    struct Model : Concept {
        T callable;
        Model(T c) : callable(std::move(c)) {}
        void invoke() override { callable(); }
    };
    
    std::unique_ptr<Concept> concept;
public:
    template<typename T>
    AnyCallable(T&& callable) 
        : concept(new Model<std::decay_t<T>>(std::forward<T>(callable))) {}
    
    void operator()() { concept->invoke(); }
};

在一个高性能交易系统的开发中，我们最初使用了大量虚函数来实现策略模式，但在性能测试中发现虚函数调用成为了瓶颈。最终我们改用基于模板的策略模式，结合CRTP技术，在保持灵活性的同时显著提升了性能。

9. 拷贝构造函数应用场景全解

9.1 拷贝构造基本概念

拷贝构造函数是一种特殊的构造函数，用于创建一个对象的副本：

cpp复制class MyClass {
public:
    // 拷贝构造函数
    MyClass(const MyClass& other) {
        // 复制other的成员到当前对象
    }
};

9.2 自动调用的四种场景

1. 显式拷贝构造：

cpp复制MyClass a;
MyClass b(a);  // 直接调用拷贝构造
MyClass c = a; // 同样调用拷贝构造

2. 函数参数传递：

cpp复制void func(MyClass param);  // 按值传递

MyClass obj;
func(obj);  // 调用拷贝构造创建param

3. 函数返回值：

cpp复制MyClass createObject() {
    MyClass localObj;
    return localObj;  // 可能调用拷贝构造（NRVO可能优化掉）
}

4. 容器操作：

cpp复制std::vector<MyClass> vec;
MyClass obj;
vec.push_back(obj);  // 调用拷贝构造

9.3 深拷贝与浅拷贝问题

1. 浅拷贝问题：

   • 默认拷贝构造函数执行成员-wise拷贝
   • 对于指针成员，只拷贝指针值，不拷贝指向的内容
   • 导致多个对象共享同一资源

2. 深拷贝解决方案：

cpp复制class String {
    char* data;
    size_t length;
public:
    // 深拷贝构造函数
    String(const String& other) 
        : length(other.length) {
        data = new char[length + 1];
        std::copy(other.data, other.data + length + 1, data);
    }
};

9.4 现代C++中的拷贝控制

C++11引入了移动语义，扩展了拷贝控制：

1. 三五法则：

   • 如果需要自定义析构函数，通常也需要自定义拷贝构造和拷贝赋值
   • 如果需要自定义拷贝构造，通常也需要自定义拷贝赋值，反之亦然
   • 如果需要自定义移动操作，通常也需要自定义拷贝操作

2. =default和=delete：

cpp复制class MyClass {
public:
    MyClass(const MyClass&) = default;  // 显式使用默认实现
    MyClass& operator=(const MyClass&) = delete;  // 禁止拷贝赋值
};

3. 移动语义集成：

cpp复制class ResourceHolder {
    Resource* res;
public:
    // 拷贝构造（深拷贝）
    ResourceHolder(const ResourceHolder& other) {
        res = new Resource(*other.res);
    }
    
    // 移动构造（资源转移）
    ResourceHolder(ResourceHolder&& other) noexcept 
        : res(other.res) {
        other.res = nullptr;
    }
};

在一个资源管理类的实现中，我最初忽略了拷贝控制，导致资源被多次释放。后来通过实现完整的拷贝构造函数、移动构造函数和析构函数，并遵循三五法则，彻底解决了资源管理问题。这个经验让我深刻理解了C++资源管理的重要性。

10. 构造与析构函数异常处理指南

10.1 构造函数异常处理

构造函数可以抛出异常，但需要特别注意资源清理：

1. 部分构造问题：

   • 构造函数抛出异常时，对象被视为未完全构造
   • 不会调用析构函数
   • 已构造的成员会自动销毁

2. 资源泄漏风险：

cpp复制class Problematic {
    int* p1;
    int* p2;
public:
    Problematic() : p1(new int(42)) {
        p2 = new int(100);
        throw std::runtime_error("Oops");  // p1泄漏！
    }
    ~Problematic() { delete p1; delete p2; }
};

3. 解决方案：
   • 使用智能指针管理资源
   • 或者使用函数try块

cpp复制class Safe {
    std::unique_ptr<int> p1;
    std::unique_ptr<int> p2;
public:
    Safe() try : p1(std::make_unique<int>(42)) {
        p2 = std::make_unique<int>(100);
        throw std::runtime_error("Oops");  // 无泄漏
    } catch(...) {
        // 清理其他资源
        throw;
    }
};

10.2 析构函数异常处理

析构函数绝对不能抛出异常，这是C++的核心准则：

1. 双重异常问题：

   • 如果析构函数在栈展开期间抛出异常
   • 程序会立即终止(std::terminate)
   • 因为无法同时处理两个异常

2. 安全实现模式：

cpp复制class SafeDestructor {
public:
    ~SafeDestructor() noexcept {
        try {
            // 可能抛出异常的操作
        } catch(...) {
            // 记录日志，但不要抛出
            logError("Destructor failed");
        }
    }
};

3. 资源释放策略：
   • 对于可能失败的操作，提供显式释放方法
   • 析构函数中调用无异常保证的版本
   • 文档说明用户应提前调用显式释放

cpp复制class FileHandler {
    FILE* file;
public:
    void close() {  // 可能抛出
        if(file && fclose(file) != 0) {
            throw std::runtime_error("Close failed");
        }
        file = nullptr;
    }
    
    ~FileHandler() noexcept {  // 不抛出
        if(file) {
            fclose(file);  // 忽略错误
        }
    }
};

10.3 异常安全保证级别

C++中有三种基本的异常安全保证：

1. 基本保证：

   • 操作失败时程序保持有效状态
   • 无资源泄漏
   • 但对象状态可能改变

2. 强保证：

   • 操作要么完全成功，要么保持原状态
   • 通常通过copy-and-swap实现

3. 不抛出保证：

   • 操作保证不会抛出异常
   • 标记为noexcept
   • 析构函数、移动操作等应尽量提供

10.4 工程实践建议

1. 构造函数设计：

   • 保持构造函数简单
   • 复杂的初始化放在单独init函数中
   • 使用工厂函数替代复杂构造

2. 析构函数设计：

   • 尽量简单可靠
   • 只做资源释放
   • 标记为noexcept

3. 资源管理：

   • 优先使用RAII对象
   • 智能指针管理内存
   • 专用类管理其他资源

在一个数据库连接池的实现中，我们最初在析构函数中尝试关闭所有连接，但连接关闭可能抛出异常。后来我们修改设计，将连接关闭作为显式操作，析构函数只处理最基础的清理，并通过状态检查确保资源不会泄漏。这种设计既保证了安全性，又提供了更好的错误处理能力。