CPP中为何优先选用class而非structure？结合示例展开说明

很多开发者在接触C++初期会误以为struct和class是功能完全割裂的两种类型，实际上二者的核心语法差异仅存在于两个默认规则上：

• struct的默认成员访问权限为public，默认继承时父类的访问权限为public
• class的默认成员访问权限为private，默认继承时父类的访问权限为private

除此之外，二者在成员定义、权限修改、多态支持等能力上完全等价。之所以在核心业务代码设计中更倾向于使用class，本质是class的默认规则与语义约定，和面向对象设计的核心目标（封装、状态约束、低耦合）匹配度更高，能从语法层面减少工程疏漏，降低团队协作成本，具体可以结合实际开发场景拆解：

1. 从默认规则层面强化封装边界，避免内部状态泄漏 #

面向对象设计的核心要求是把对象的不变量（即对象永远需要满足的状态规则）收敛在内部，禁止外部代码随意修改内部状态。如果使用struct做业务实体，默认全public的成员规则很容易让开发过程中遗漏权限控制，直接破坏对象的合法状态。

举个简单的圆形计算类例子：
如果用struct实现，默认所有成员都是公开可改的：

// 基于struct的圆形实现，无任何权限控制
struct CircleStruct {
    double radius;
    double center_x;
    double center_y;

    double calc_area() {
        return 3.14159 * radius * radius;
    }
};

外部代码可以随意绕过业务规则修改成员，直接产生非法对象：

int main() {
    CircleStruct c{1.0, 0, 0};
    c.radius = -5.0; // 直接破坏“半径必须大于0”的基本业务规则
    double area = c.calc_area(); // 计算逻辑不会拦截非法状态，最终产生逻辑错误
}

如果替换为class实现，默认所有成员都是私有的，开发时会自然把需要对外暴露的接口通过public关键字显式标注，从流程上就会主动补上状态校验逻辑：

// 基于class的圆形实现，默认成员私有，仅暴露受控接口
class CircleClass {
    // 内部属性默认私有，外部完全无法直接访问
    double radius_;
    double center_x_;
    double center_y_;

public:
    CircleClass(double r, double x, double y) {
        // 构造时校验状态合法性，保证对象从创建之初就是合法的
        if (r <= 0) {
            throw std::invalid_argument("半径必须大于0");
        }
        radius_ = r;
        center_x_ = x;
        center_y_ = y;
    }

    void set_radius(double r) {
        // 修改状态时再次校验，避免后续修改产生非法值
        if (r <= 0) {
            throw std::invalid_argument("半径必须大于0");
        }
        radius_ = r;
    }

    double calc_area() const {
        return 3.14159 * radius_ * radius_;
    }
};

这里的核心差异不是“struct不能写private、不能做校验”，而是默认规则会引导开发行为：class会默认把所有内部实现藏起来，需要暴露时再主动放开权限；而struct会默认把所有内部细节放出去，很容易在迭代开发中因为忘记加权限控制，把内部实现细节直接变成外部代码的依赖，后续修改内部结构时就会产生大面积的适配成本。

2. 语义约定统一，降低团队协作的理解成本 #

经过长期的工程实践，C++社区已经形成了通用的类型语义约定，不同关键字对应的类型有明确的使用场景：

• struct仅用于无状态约束的纯数据聚合（POD，Plain Old Data）：类型只承载字段数据，没有任何绑定的行为逻辑、没有需要维护的状态不变量，所有成员允许外部直接读写，比如跨层传输的网络包结构、文件头结构、API接口的请求/响应参数等。
• class仅用于有独立行为、有严格状态约束的业务实体：类型有明确的生命周期、内部状态流转规则，对外只暴露受控的行为接口，不允许外部直接修改内部状态。

这种约定在多人大规模协作的项目中价值极高，比如在电商订单模块开发中：
如果把核心订单实体写成struct，其他开发者看到这个类型的第一反应是“这是一个可以随便赋值字段的纯数据结构”，很可能在业务代码里直接写order.pay_status = "paid"，完全跳过支付校验、状态流转的逻辑，直接产生资损类的bug。
如果把核心订单实体写成class，其他开发者看到这个类型的第一反应是“这是一个有严格规则的业务对象，不能直接修改内部字段，必须调用类提供的pay()、refund()等受控方法”，自然会遵守封装的边界。

举个符合语义约定的对比例子：

// 适合用struct的场景：跨API层传输的订单快照，无逻辑、无状态约束
struct OrderSnapshot {
    std::string order_id;
    double total_amount;
    std::string user_id;
    long long create_timestamp;
};

// 适合用class的场景：承载订单业务规则的核心实体
class Order {
    // 内部状态、金额等字段全部私有，外部无法直接修改
    std::string order_id_;
    double total_amount_;
    OrderStatus status_;

public:
    // 仅暴露受控的状态修改接口，内部强制校验流转规则
    void pay(PaymentChannel channel) {
        if (status_ != OrderStatus::PENDING_PAY) {
            throw std::logic_error("当前订单状态不支持支付");
        }
        // 支付流程的实际处理逻辑
        status_ = OrderStatus::PAID;
    }
};

3. 适配继承与多态设计，减少冗余的权限配置 #

面向对象设计中经常用到继承与多态来实现接口抽象，这就需要清晰的三级权限分层：只有类自己能访问的私有成员、仅派生类能访问的受保护成员、所有外部代码能访问的公开成员。

如果使用struct构建继承体系，默认的public权限会让派生类很容易接触到基类的内部实现细节，破坏基类的封装性。比如做一个图形渲染的抽象基类：

// 用struct实现的渲染基类，默认所有成员都是public
struct RenderableStruct {
    // 本来是基类内部用的调试上下文，因为struct的默认规则直接暴露给所有代码
    RenderContext* debug_ctx_;
    RenderContext* ctx_;

    virtual void draw() = 0;
    virtual ~RenderableStruct() = default;
};

如果换成class实现，默认的private规则会让开发者主动把需要暴露给派生类的成员标记为protected，不需要暴露的细节留在private域，整个权限分层是天然清晰的：

class RenderableClass {
    // 完全私有，只有类自己能访问，派生类也无法触碰
    RenderContext* debug_ctx_;

protected:
    // 受保护，仅派生类可以访问
    RenderContext* ctx_;

public:
    // 公开的抽象接口，所有外部代码都可以调用
    virtual void draw() = 0;
    virtual ~RenderableClass() = default;
};

这种设计下，基类的内部细节不会随意泄漏到派生类或外部代码中，整个继承体系的耦合度会低很多。

最后需要说明的是，这不是说struct完全没有使用场景——针对纯数据聚合的简单类型，struct因为默认public的规则，写起来更简洁，完全适合用struct开发。只是在做核心业务逻辑、面向对象抽象的代码设计时，class的默认规则和语义约定能最大程度贴合开发目标，减少不必要的疏漏。

内容的提问来源于stack exchange，提问作者Morshedul Munna