1. 先把结论摆上台面：Struct 和 Class 到底差在哪
刚入行那会儿，我在一个老项目里看到满屏的struct里塞着构造函数、虚函数和私有成员，而另一个文件里的class又只写了三个double，我当时的第一反应是"这代码风格也太野了"。后来带我的老哥只回了一句：编译器根本不在乎你写的是struct还是class。这句话我记了很多年，但它只说对了一半。C++ 中的struct和class确实是同一套对象模型的两种写法，可它们之间那条唯一的语言级硬差异——默认访问权限和默认继承权限——恰恰是决定代码可读性、封装边界和跨语言兼容性的关键。这篇文章就围绕这条差异展开，把内存布局、对象模型、使用场景、重构步骤、调试排查这几块讲透，适合刚学完 C++ 语法、正在纠结"这两个关键字该用哪个"的同学，也适合写了几年 C++ 但没认真梳理过默认规则的老手。看完你至少能回答三个问题：它们编译后是不是一样、什么情况下必须用struct、把一个struct改成class需要动哪些地方。
1.1 唯一的硬差异：默认权限
C++ 标准里对这两者的定义非常干脆：用class定义的类型，其成员和基类的默认访问权限是private；用struct定义的类型，默认是public。就这一条。注意措辞，是"默认"，不是"只能"。你完全可以在struct里写private:，也可以在class里第一行就写public:，编译器一视同仁。
struct S { int a; // public，因为默认就是 public private: int b; // 手动收紧 }; class C { int a; // private，因为默认就是 private public: int b; // 手动放开 };继承也一样：
struct DerivedStruct : Base {}; // 等价于 public Base class DerivedClass : Base {}; // 等价于 private Base第二行那个private继承是很多人翻车的地方。class DerivedClass : Base之后，Base里的 public 成员在DerivedClass外部全都访问不到，甚至不能再隐式转回Base&。我见过有人在重构时把struct改成class，忘了显式补上public继承，结果一堆多态调用直接编译不过，报错信息还是一长串模板展开，排查半小时才发现是这一行的事。所以记住一句话：改关键字可以，继承列表前面的public必须自己补。
注意：
class和struct作为模板类型参数的声明符是完全等价的，template<class T>和template<typename T>没区别，写哪个纯看团队约定。
1.2 编译之后它们是不是同一个东西
是。一旦编译到目标文件层面，struct S和把首行换成public:的class C，生成的符号、内存布局、虚函数表结构可以做到逐字节一致。访问权限是纯粹的编译期检查，它不占用任何运行时空间，也不会生成额外指令。换句话说，sizeof、对齐、vtable 布局，跟关键字选择无关，只跟成员构成、继承关系、是否有虚函数有关。
这里有个常被误解的点：很多人以为struct天生就是 POD（Plain Old Data），能直接memcpy；class就不行。这个判断是错的。判断能不能安全memcpy，要看它是不是trivially copyable或者standard layout，也就是有没有虚函数、有没有自定义拷贝构造/析构、成员访问权限是否一致等，跟关键字本身没关系。一个全是 public 成员的struct，只要加了虚函数或者自定义析构，照样不能memcpy；反过来一个成员全是 public 的class，一样是标准布局类型。C++11 之后标准库给了std::is_trivially_copyable<T>、std::is_standard_layout<T>这些 trait，需要判断时直接查，别凭关键字猜。
1.3 "它们没区别"这句话为什么容易误导人
说"没区别"的人通常指的是编译产物没区别，这点没错。但落到工程实践上，关键字承担的是一种意图声明。读代码的人看到struct Point { double x, y; };，脑子里立刻建立"这是一个纯数据聚合体，成员公开，随便读写"的预期；看到class Connection { ... };，就会预期"这里有封装、有生命周期管理、有不变式"。这种预期靠的是行业约定，不是语言强制，但它极大降低了沟通成本。
反过来，如果一个struct里藏着私有成员和虚函数，审查代码的人会本能地提高警惕，因为"它看起来是数据，实际是对象"。我给团队定过一条很朴素的规矩：struct只用来装数据，一旦需要保护成员或定义不变式，就换成class。这条规矩不涉及任何技术强制，但它省下了大量"这到底能不能直接改"的来回确认。
2. 编译期到底发生了什么：对象模型与内存对齐
要真正理解两者的"同"，得把对象模型拆开看。很多同学学 C++ 时把类和对象当成黑盒，遇到sizeof对不上、调试器里看不到成员、序列化出来字节错位这些问题时就抓瞎。实际上这些问题全都落在同一套规则里：成员排列、对齐填充、虚表指针。这部分内容跟关键字无关，但它是判断"什么时候能用struct"的基础。
2.1 成员变量、虚函数表与对象大小
一个不含虚函数的类型，对象里只放非静态数据成员，静态成员不占空间（它们存在静态存储区）。一旦类里出现虚函数，编译器通常会在对象头部塞一个虚表指针（vptr），64 位平台上一般是 8 字节。这就是为什么一个只有一个int成员的类，加上虚函数后sizeof从 4 变成 16——4 字节数据 + 4 字节填充 + 8 字节 vptr。
struct Plain { int a; }; // sizeof = 4 struct WithVirtual { int a; virtual void f(); }; // sizeof = 16（64 位，典型实现）注意"典型实现"这个措辞。C++ 标准没有规定 vptr 必须存在、必须放在开头，也没规定虚函数表怎么组织，这些都属于 ABI（应用二进制接口）层面的约定。GCC/Clang 在 Linux 上遵循 Itanium ABI，MSVC 有自己的布局方案，两者在多重继承、虚基类场景下的排布可能有差异。所以做跨编译器二进制对接时，别直接传带虚函数的对象，要传就传 POD 结构体。
2.2 对齐与填充：为什么 sizeof 总比你以为的大
这是新手最容易踩的坑。CPU 访问内存时对地址有对齐要求，编译器为了保证每个成员都落在合适的地址上，会在成员之间插入填充字节。规则就两条：
- 每个成员的偏移量必须是它自身对齐值的整数倍；
- 整个结构体的大小必须是最大成员对齐值的整数倍。
struct A { char a; int b; char c; }; // sizeof = 12，不是 6拆开看：a在偏移 0，占 1 字节；b是int，对齐 4，所以偏移 1、2、3 三个字节被填掉，b落在偏移 4；c在偏移 8；整体最大对齐是 4，总大小要凑到 4 的倍数，所以补到 12。如果调整顺序：
struct B { int b; char a; char c; }; // sizeof = 8同样的成员换个顺序，省了 4 字节。这就是所谓的结构体成员重排优化。在嵌入式或者网络协议打包场景，这几个字节可能很要命。
需要精确控制布局时，用#pragma pack或者__attribute__((packed))关掉填充。但我得提醒一句：
注意：打包结构体虽然省空间，但成员可能落在非对齐地址上，在部分架构（比如某些 ARM 配置）上访问会触发硬件异常或者性能骤降。用之前先确认目标平台支不支持非对齐访问，或者干脆用
memcpy逐字段搬运。
2.3 空类为什么占 1 字节，以及空基类优化
struct Empty {};的sizeof是 1，不是 0。原因很实在：如果两个对象大小是 0，它们在内存里就可能拿到同一个地址，那样&a == &b就成立了，对象身份没法区分。所以标准要求完整对象至少占 1 字节。
但在做基类时，这 1 字节可以被省掉，叫空基类优化（EBCO）：
struct Empty {}; struct Holder : Empty { int x; }; // sizeof 通常是 4，不是 8这个特性在标准库里被大量使用，比如某些实现里std::vector把空分配器作为基类，就不额外占空间。这也是"用继承代替成员"的一种少见但合理的理由。不过别为了省这几个字节把设计搞乱，可读性永远优先。
3. 使用场景拆解：什么时候用 Struct，什么时候用 Class
把原理讲完，终于到最有价值的部分。我不想给你一个"全凭喜好"的敷衍答案，而是按场景分类，每条都说明理由。
3.1 数据聚合体：坐标、配置、协议报文
结论：用struct。典型例子是二维坐标、矩形区域、颜色值、解析出来的配置项、网络报文头。
struct Vec2 { double x{}; double y{}; }; struct Rect { int left{}, top{}, right{}, bottom{}; int width() const noexcept { return right - left; } int height() const noexcept { return bottom - top; } };为什么是struct：成员全是公开数据，没有需要维护的不变式，聚合初始化（Vec2 v{1.0, 2.0}）和指定初始化（C++20 的Vec2 v{.x = 1.0, .y = 2.0}）都能直接工作，序列化时直接按字节或字段处理。这类类型经常需要拷贝、传值、放进std::vector，公开成员让它天然适合做 DTO（数据传输对象）。
这里可以补一句：指定初始化只对聚合类型有效。一个类型是不是聚合，要求之一就是没有 private 或 protected 的非静态数据成员、没有用户声明的构造函数、没有虚函数。所以你把上面这个struct改成class且不补public:，聚合初始化立刻失效，Vec2 v{1.0, 2.0}会报错。这是很实际的迁移成本。
3.2 带不变式的资源管理者：用 Class
一旦类型需要维护某种"永远成立的条件"，比如"文件句柄必须有效或者为空""温度不能低于绝对零度""连接状态和内部缓冲区必须同步"，就该上class。
class FileHandle { public: explicit FileHandle(const std::string& path) : fp_(std::fopen(path.c_str(), "rb")) { if (!fp_) throw std::runtime_error("open failed: " + path); } ~FileHandle() { if (fp_) std::fclose(fp_); } FileHandle(const FileHandle&) = delete; FileHandle& operator=(const FileHandle&) = delete; FileHandle(FileHandle&& o) noexcept : fp_(o.fp_) { o.fp_ = nullptr; } std::size_t read(void* buf, std::size_t n) { return std::fread(buf, 1, n, fp_); } private: std::FILE* fp_; };这个类的价值不在于"成员是私有的"，而在于它把fclose这件事绑定到了析构函数，也就是 RAII。外部代码不可能忘记关闭文件，也不可能在对象还活着的时候把fp_改成一个野指针。如果写成struct加公开的FILE* fp;，那么每个使用点都得自己保证配对的fopen/fclose，一个异常路径漏掉就是资源泄漏，而且没人拦得住别人去写h.fp = nullptr;。
我的判断标准很直接：如果这个类型的成员能被外部随意改成非法组合，就应该用class把入口收窄。
3.3 接口与多态：抽象基类
定义纯虚接口时，一律用class：
class IEncoder { public: virtual ~IEncoder() = default; virtual std::vector<std::uint8_t> encode(const Frame& f) = 0; virtual bool decode(const std::uint8_t* data, std::size_t len, Frame& out) = 0; };理由有两条。一是可读性，class加纯虚函数是行业里公认的"这是接口"的信号；二是安全性，如果用struct又忘了写public:，struct默认是 public 所以不会出问题，但用class忘了写，所有虚函数变成私有，派生类无法实现，编译器报错会绕一大圈。更重要的是，基类析构函数必须声明为virtual，否则通过基类指针delete派生对象是未定义行为。这一点跟关键字无关，但接口定义场景下必须写进去。
另外提一句final和override：接口类上标final可以阻止别人继承，做类型擦除时有用；派生类里每个覆写函数都写override，能让"签名写错导致没真正覆写"这个经典错误在编译期暴露。我见过因为参数少了个const导致虚函数没生效、调了半天运行时的案例，加上override一秒钟就定位了。
3.4 跨语言与跨进程边界：Struct 的主场
只要涉及 C ABI，比如给 C 程序调用、做动态库导出、和脚本语言通过 FFI 交互、写共享内存协议，就必须用struct。原因是 C 只有struct概念，而且它的布局规则简单明确，没有访问权限、没有虚表、没有默认构造。
extern "C" { struct SensorReading { std::uint32_t id; float temperature; float humidity; }; }配套注意点：内部用std::uint32_t这类定宽整数；字段顺序和对齐要和对方严格对齐，必要时加static_assert把大小钉死：
static_assert(sizeof(SensorReading) == 12, "layout changed, check protocol");这条static_assert值千金。哪天有人手滑调了字段顺序或者换了类型，编译直接失败，而不是等到对接现场数据全乱。同样的思路也适用于 Qt 里用 JSON 做配置的场景：一个struct AppConfig负责承接解析结果，序列化和反序列化函数单独写，配置结构本身保持纯数据，不掺业务逻辑。这样 JSON 字段变了，只改映射函数，数据结构不动。
4. 实操：把一个裸 Struct 改成带约束的 Class
光讲道理不够，走一遍完整改造。假设我们在做一个温度采集模块，最初是这么写的：
struct Temperature { double celsius; };需求来了：这个值会被送到传感器驱动，低于 -273.15 或高于某个上限会导致驱动报错；同时界面上要显示华氏度；还要能记录修改时间。下面分步拆。
4.1 第一步：确定哪些是不变式
先把约束列清楚。
| 约束 | 说明 | 处理方式 |
|---|---|---|
| 下限 | 不得低于绝对零度 -273.15 | 构造和赋值时检查 |
| 上限 | 不得超过传感器量程 1000.0 | 构造和赋值时检查 |
| 单位换算 | 需要华氏度视图 | 提供只读接口 |
| 修改时间 | 每次变更记录 | 内部成员维护 |
这里的关键判断是：这些约束是"任意时刻都必须成立"的，所以它们属于不变式，应该由类型自己保证。如果只是某个函数内部的临时检查，那留在函数里就行。区分这两者是设计的第一步。
4.2 第二步：动手改造，把入口收窄
#include <stdexcept> #include <chrono> class Temperature { public: Temperature() = default; explicit Temperature(double celsius) { set(celsius); } double celsius() const noexcept { return celsius_; } double fahrenheit() const noexcept { return celsius_ * 9.0 / 5.0 + 32.0; } void set(double v) { if (!(v >= kMinCelsius && v <= kMaxCelsius)) { throw std::out_of_range("temperature out of range"); } celsius_ = v; lastModified_ = std::chrono::steady_clock::now(); } auto lastModified() const noexcept { return lastModified_; } private: static constexpr double kMinCelsius = -273.15; static constexpr double kMaxCelsius = 1000.0; double celsius_{}; std::chrono::steady_clock::time_point lastModified_{}; };注意几个细节。第一，判断写成!(v >= min && v <= max)而不是v < min || v > max，这样NaN会被判为非法——NaN 跟任何数比较都是 false，用后一种写法NaN会悄悄溜进去。这是数值类型校验里很实用的一个小技巧。第二，构造函数标explicit，防止double隐式转成Temperature，避免函数重载时出现意料之外的匹配。第三，default构造函数保留了默认构造能力，celsius_用花括号初始化成 0，这个 0 落在合法区间内，所以不用额外检查。
4.3 第三步：处理拷贝、序列化和聚合初始化的损失
改造完之后，原来代码里所有Temperature t{25.0};还能用吗？能，因为explicit构造函数接收一个double，花括号初始化会匹配它。但Temperature t{25.0, someTime};这种两参数聚合初始化不行了，因为类型不再是聚合。这是必须接受的取舍。
如果这个类型要序列化进 JSON 或者写进共享内存，就得自己加转换函数：
struct TemperaturePod { // 纯粹用于传输 double celsius; }; TemperaturePod toPod(const Temperature& t) { return {t.celsius()}; } Temperature fromPod(const TemperaturePod& p) { return Temperature{p.celsius}; }这里的思路是内外分离：内部用带约束的class，对外传输用纯struct。很多人试图让一个类型同时承担这两件事，结果要么牺牲封装，要么序列化时到处friend，越写越乱。
再补一个性能视角。改造之后增加了边界检查，每次set多一次比较和一次时钟读取。steady_clock::now()在某些平台上不是完全免费的，如果这个 setter 在热路径上被调几百万次，就得考虑把时间戳记录改成可选，或者用更轻的计数方案。我实测过一个类似场景，把时钟读取从每次 set 改成批量提交后记录，吞吐提升了接近三成。封装不是无代价的，关键是代价花在值不值的地方。
4.4 工具链配置：让编译器帮你把关
改完代码，把警告等级开满。GCC/Clang 用-Wall -Wextra -Wpedantic，MSVC 用/W4。再打开-Wreorder（成员初始化列表顺序和声明顺序不一致会警告）和-Wshadow（变量遮蔽）。地址消毒剂在调试阶段很好用：-fsanitize=address,undefined，能抓到不少越界和未定义行为。
VS Code 里如果遇到结构体成员补全失效，大概率是 IntelliSense 找不到头文件。检查.vscode/c_cpp_properties.json里的includePath有没有覆盖你的第三方库目录，compilerPath指向的是不是实际用的编译器。热词里提到的"结构体成员补全错误"，九成是这个原因，跟代码本身没关系。
5. 常见坑与排查实录
这一节是我这些年攒下来的实际问题，按排查表加案例的形式整理。
5.1 高频问题速查表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
改了class后多态调用编译不过 | 继承了但没写public | 检查继承列表 |
sizeof和手工计算对不上 | 对齐填充 | 用offsetof逐个打印偏移 |
| 序列化后对方解析错位 | 结构体被 pack 或字段顺序变了 | 加static_assert(sizeof(...)) |
| 调试器里结构体成员看不到 | 编译优化把变量优化掉了 | 降优化等级或加volatile |
| 成员补全失效 | IntelliSense 找不到头文件 | 检查includePath |
memcpy后程序偶发崩溃 | 类型不是 trivially copyable | 用 trait 静态断言 |
| 聚合初始化报错 | 类型不再是聚合 | 检查是否有私有成员或自定义构造 |
5.2 调试器里看结构体：Keil、GDB、VS 各有各的脾气
嵌入式场景用 Keil MDK 调结构体变量，坑比较集中。首先是优化等级，-O2以上经常把只被读一次的局部变量优化进寄存器，Watch 窗口里显示cannot evaluate。解决办法是把调试构建改成-O0，或者给关键变量加volatile。其次，Watch 窗口里要输入结构体变量名，展开左侧小三角才能看到成员；如果变量是指针，要写(*ptr)或者ptr->member。另外记得打开View -> Periodic Window Update，否则全速运行时窗口里的值不刷新。
GDB 侧舒服很多，p *ptr、p obj直接出结构，set print pretty on让嵌套结构体换行显示，ptype obj看完整定义，p/x obj按十六进制看。排查内存布局问题时，p &obj配合offsetof宏打印各成员偏移，一眼就能确认填充。
Visual Studio 的监视窗口支持obj.member和obj, n（n 是展开层数），还有内存窗口可以直接看原始字节。我排查过一次结构体对齐问题，就是靠内存窗口对照十六进制确认了成员之间的填充字节数。
5.3 文件读取结构体：fscanf 和二进制读的坑
从文本文件读数据填进结构体，fscanf是常用手段：
struct Record { int id; char name[32]; double score; }; Record r{}; if (std::fscanf(fp, "%d %31s %lf", &r.id, r.name, &r.score) != 3) { // 处理解析失败 }这里三个坑。第一，%s不带宽度限制会溢出name，必须写%31s（留一个位置给结束符）。第二，返回值必须检查，少于 3 说明某个字段没读到，此时结构体里的值是部分更新的脏数据。第三，name是数组，传参时不用取地址，写r.name而不是&r.name，虽然两者地址值相同但类型不同。如果是二进制读取，别直接fread(&r, sizeof(r), 1, fp)一把梭，因为double的字节序、int的宽度、结构体填充都会因平台而异，跨平台一定逐字段读写或者用定宽类型加显式序列化。
5.4 别把 C++ 的 class 和别的语言混着理解
顺手澄清几个跨语言带来的误解。Python 里的class是运行时对象，能动态加属性、改方法，跟 C++ 的编译期类型完全不是一回事；Java 的Object类是所有类的根，C++ 没有这种统一根类；C# 的class是引用类型而struct是值类型，这个"值/引用"的区别在 C++ 里根本不存在——C++ 的struct和class都是值类型，想用引用语义得自己用指针或std::reference_wrapper。还有 Go 语言用反射把结果填进结构体、PHP 里改 class 定义这些操作，放在 C++ 里对应的就是"编译期确定布局，运行时只读"，思路要换过来。
6. 工程规范怎么落地：给团队的约定与评审清单
原理和实操都讲完了，最后落到团队协作。这类"关键字选择"的问题，个人怎么写都能跑，但一个项目里混着来，维护成本会明显上升。
6.1 一份可以直接抄的约定
我目前在用的约定是这样几条，写在项目根目录的编码规范里。
struct只用于纯数据聚合：全部非静态数据成员公开，没有需要维护的不变式，可以安全拷贝。- 一旦出现私有成员、
virtual函数、用户声明的析构函数、或者需要对成员做合法性校验，改成class。 - 用于 C ABI 导出的类型，一律
struct，且加static_assert校验大小。 - 抽象接口一律
class，析构函数声明virtual，纯虚函数后面加= 0。 - 从
struct改class时，必须显式写public:和public继承，且检查聚合初始化调用点。
这套约定的好处是判断标准可量化——不是"你觉得哪个好看"，而是"有没有私有成员、有没有虚函数"。代码评审时可以直接对照，不用争论。
6.2 评审时我会重点看的几处
- 这个类型有没有不变式？有的话，所有修改入口是不是都做了校验？
- 类里有没有裸的资源句柄成员，析构函数有没有正确释放，拷贝语义有没有处理（要么禁掉，要么实现深拷贝）？
- 有虚函数的基类，析构函数是不是
virtual？ - 需要在外部做二进制兼容的结构体，有没有
static_assert锁大小？ - 是否存在"看起来是 struct 实际有私有成员"的类型？有的话是历史遗留还是设计需要，能不能统一。
最后分享一个我自己的小习惯：每个模块开头写一句注释，说明这个模块里struct的定位是什么，是"纯数据"还是"兼容旧代码"。这句话不占几行，但能让半年后接手的人立刻明白设计边界，比任何文档都管用。毕竟struct和class的选择从来不是语法题，而是把"这个类型想对外暴露多少"这件事写进代码里的方式。
