小狐狸与小道士1. 先从整体上理解：类成员到底在管哪些事
写 C++ 的人，天天跟类打交道，但“类成员”这个词其实涵盖了好几类东西。我见过不少刚入门的朋友以为成员就是类里面声明的变量和函数，这个理解没错，但不够。真正把类成员吃透，至少要把四类东西分清楚：数据成员、成员函数、特殊成员函数、访问控制，另外还有一类容易忽略的“类型成员”（typedef、using 别名、嵌套类）。
为什么这个区分重要？因为 C++ 类的行为差异，绝大部分就来自这四类细节的组合。比如数据成员有普通的实例成员，也有 static 共享成员，还有 const 成员、引用成员；成员函数有普通函数、const 成员函数、static 成员函数、虚函数、纯虚函数。每一种都不是随便写的，选了哪个，意味着对象在内存里长什么样、能不能在 const 对象上调用、是否需要类外定义、能不能继承覆盖……全都不一样。
我尽量不讲成文法，而是带着你从“设计一个类”的角度走一遍，比如拿一个 Student 类当例子贯穿全文。看明白这类常规设计之后，再去看其他复杂的类，思路会顺很多。
核心的一句话：类成员的本质，是“数据 + 行为 + 权限 + 生命周期”的统一封装。你在类里写的每一个成员，都要同时考虑这四个维度，缺一个，后面就会出问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. public/private/protected：访问控制不是摆设
2.1 三种访问限定的真实差异
还是用代码说事。先看一个尽可能简单的例子：
cpp复制class Student {
public:
void setName(const std::string& name) {
name_ = name;
}
std::string getName() const {
return name_;
}
private:
std::string name_;
int age_ = 0;
};
这里 public 区提供接口，private 区保存实现细节。Age 没有对应的 setter，所以外部无法随便改变年龄，这就叫封装。你可能会问：这有什么实际好处？最直接的好处是，将来想校验年龄（比如必须在 0~150 之间），只需要在类的内部加逻辑，外部代码完全不用动。如果当初把 age_ 直接 public 暴露出去，全工程到处都能写 stu.age_ = -5，那就失控了。
protected 的情况稍微特殊：它的含义是“派生类可见，外部不可见”。需要注意的是，很多新人不理解 protected 的真实边界。protected 成员不是“子类对象可以随便访问基类对象的 protected 成员”，而是“子类代码可以访问自己或父类对象内部的 protected 成员”。比如两个 Student 对象之间不能通过 protected 成员互相访问，但同一个类的成员函数内部可以。区别微妙，写多继承时很容易踩坑。
2.2 封装设计的一个实用原则
我个人的经验是：数据成员一律 private，对外能提供的操作通过 public 成员函数暴露。如果想让派生类也能用某些内部数据，再用 protected；但 protected 数据成员用多了会破坏基类的封装性，因为派生类会直接依赖这些布局，导致父类一改、子类全崩。所以 protected 优先给虚函数和工具函数，而不是给裸数据。
这里补充一个被很多人忽略但很重要的原则：能用自由函数解决的问题，尽量不要用成员函数，除非它真的需要访问私有成员。这是 Meyers 在《Effective C++》里强调过的封装思想。成员函数越多，类的公共接口越膨胀，改动成本越高。比如一个计算平均分的函数，如果它只需要通过 public 接口读取学生成绩，就写成自由函数更利于扩展。
注意：struct 和 class 在 C++ 里唯一的区别是默认访问权限。struct 默认 public，class 默认 private。语义上 struct 更适合用来聚合数据，class 适合封装行为。能用 struct 就别硬套 class。
3. 数据成员分类与内存布局：规划对象的结构
3.1 实例数据成员、静态成员、常量成员
数据成员大致有几类，每一类的初始化和存储方式差异很大：
普通实例成员：每个对象一份，生命周期跟对象一致。一般在构造函数初始化列表里初始化，或者在声明处用默认值初始化（C++11 之后推荐优先用后者）。
static 成员：所有对象共享一份，本质上是“藏在类作用域里的全局变量”。需要特别注意，C++17 之前，非 const 的 static 数据成员必须在类外定义一次，否则链接报错。C++17 以后可以用 inline static 在类内直接初始化。
const 成员：必须在构造函数初始化列表初始化，不能在声明处赋值之后再改。这里有个常见误区，就是以为 const 成员只是在构造函数里赋值一下就行，但实际上它一旦构造完成，整个生命周期内都不能改。所以需要运行时才能确定的常量，建议用 static const 或者枚举替代。
引用成员：和 const 成员类似，也必须在初始化列表绑定，而且一旦绑定就不能换对象。引用成员会让类失去默认赋值能力，因为引用不能重新绑定。如果类里有引用成员，拷贝赋值运算符会被默认删除掉，这个坑很多人没意识到。
下面给个示例：
cpp复制class Student {
public:
Student(int id, const std::string& name)
: id_(id), name_(name), ref_id_(id_) {}
private:
int id_;
std::string name_;
int& ref_id_; // 引用成员，必须在初始化列表绑定
static inline int total_count_ = 0; // C++17 inline static
};
3.2 内存对齐与成员顺序
对象在内存中并不是简单地把成员依次排列，中间会有内存对齐（alignment）填充。比如一个类有三个成员：char、int、char，如果按声明顺序排列，char 占 1 字节后要补 3 字节对齐到 int，然后 int 占 4 字节，再补 3 字节对齐到下一个 char 的倍数……最终大小很可能不是 6 而是 12。
高情商说叫“内存布局优化”，低情商说就是浪费空间。如果你特别在意对象体积（比如在内存池、缓存行优化中），可以把大尺寸的类型往前放，小尺寸的往后放，能让填充变少。
cpp复制class BadOrder {
char a;
int b;
char c;
};
class GoodOrder {
int b;
char a;
char c;
};
后者的体积通常比前者小。真实项目里如果成千上万个对象，这个差异会影响缓存命中率。不过在初级学习阶段，不用过度优化，但至少要知道什么原因导致 sizeof 不等于成员大小之和。
3.3 初始化列表顺序的坑
构造函数初始化列表的执行顺序，是按类中数据成员的声明顺序，而不是初始化列表里的书写顺序。很多新手会以为初始化列表从上到下执行，于是写出这样危险的代码：
cpp复制class Result {
public:
Result(int a) : b_(a), a_(b_) {} // b_ 先初始化，此时 a_ 还没初始化！
private:
int a_;
int b_;
};
这段代码里 a_ 声明在前，所以先初始化 a_，但 a_ 的初始化值取自 b_，此刻 b_ 还没被初始化，于是 a_ 拿到的是一个未定义值。编译器通常会给出 -Wreorder 警告，但很多人没开警告，或者直接忽略了。最好的做法是：让初始化列表顺序跟声明顺序保持一致，并且尽量不要用其他成员来初始化成员。编译器对“成员的初始化顺序和声明顺序不一致”这件事，会警告但不报错，所以非常隐蔽。
3.4 mutable：只在小范围内打破 const
mutable 的意思是“即使在 const 成员函数里也可以被修改”。它的用途非常明确：缓存、统计、锁、引用计数这类不影响“对象逻辑状态”的成员。比如一个缓存查询结果的类，查询本身是 const 操作，但内部想缓存上次结果，此时缓存变量就应该声明为 mutable。
cpp复制class DataLoader {
public:
std::string getData() const {
if (cache_valid_) return cache_;
// 模拟读取
cache_ = "some heavy data";
cache_valid_ = true;
return cache_;
}
private:
mutable std::string cache_;
mutable bool cache_valid_ = false;
};
这里如果 cache_ 不声明成 mutable，const 成员函数里就无法给 cache_ 赋值，那这个“逻辑只读但物理可变”的需求就实现不了。注意 mutable 不要滥用，它本质上是脱开 const 约束的一个后门，用它的时候要想清楚：这个成员真的不属于对象的逻辑状态吗？如果是，可以用；如果不是，说明设计有问题。
4. 成员函数：const、static、virtual、inline 怎么选
4.1 普通成员函数 vs const 成员函数
写成 const 成员函数（声明尾部加 const），意味着这个函数承诺不会修改对象的逻辑状态。它有两个作用：第一，const 对象只能调用 const 成员函数；第二，非 const 对象也能调用 const 函数，所以把一个应该是只读的函数标记为 const，接口更灵活。反之，如果该加的 const 没加，那 const 对象或者 const 引用就调用不了这个函数，非常被动。
一个实用判断法：如果这个成员函数不修改任何数据成员，或者修改的都是 mutable 成员，就把它写成 const。需要注意的是 const 限制的是函数内部对成员的修改能力，不是限制函数内局部变量。比如：
cpp复制int getAge() const {
int local = age_ + 1; // 可以，local 是局部变量
return age_;
}
4.2 static 成员函数
static 成员函数不依赖具体对象，不能访问 this，也不能访问非静态数据成员。它本质上就是定义在命名空间里的普通函数，只不过放在类的内部，可以访问类的私有静态成员。常见的用途有：工厂函数、工具函数、访问单例实例等。
cpp复制class Student {
public:
static Student createDefault() {
return Student(0, "unknown");
}
static int getTotalCount() {
return total_count_;
}
private:
static inline int total_count_ = 0;
};
和全局自由函数相比，static 成员函数的好处是能直接访问 private 区，坏处是会占用一个类名相关的名字，并且可能让类的接口变大。所以同样遵循能自由函数就自由函数的原则，但如果是访问 private 成员，static 成员函数很合适。
4.3 虚函数与纯虚函数
虚函数的意义在于实现多态：通过基类指针/引用调用时，会动态分派到实际对象版本的函数。设计虚函数时要特别考虑两件事：析构函数要不要虚、基类是否应该有纯虚函数。
如果你设计一个类就是当基类用的，一般应该把析构函数声明为 virtual。否则通过基类指针 delete 派生类对象时，只会调用基类析构函数，派生类部分可能不会正确释放，导致资源泄漏或未定义行为。纯虚函数则让基类成为抽象类，不能直接实例化，强制派生类实现接口。比如：
cpp复制class Person {
public:
virtual ~Person() = default;
virtual std::string role() const = 0; // 纯虚函数
};
class Student : public Person {
public:
std::string role() const override { return "student"; }
};
这里 role() 的 override 关键字是 C++11 引入的，建议在任何覆写虚函数的地方都加上，编译器能帮助你检查函数签名是否真的重写成功了。
4.4 inline 和成员函数定义位置
在类内部直接定义的成员函数，默认是 inline 的。这个 inline 的含义不是“一定内联展开”，而是允许该函数在多个编译单元中出现重复定义，而不会导致链接错误。如果你在类外定义成员函数，并且希望跨编译单元内联，最好显式加 inline。这个细节在写头文件里的类模板或工具类时比较重要。
还需要提一下 constexpr。如果类非常简单，比如存储颜色 RGB 的结构体，构造函数和 getter 都可以标记成 constexpr，这样对象可以在编译期求值。它跟 inline 是不同维度的问题，但经常一起出现，代码里常见的写法：
cpp复制class RgbColor {
public:
constexpr RgbColor(uint8_t r, uint8_t g, uint8_t b) : r_(r), g_(g), b_(b) {}
constexpr uint8_t r() const { return r_; }
private:
uint8_t r_, g_, b_;
};
5. 特殊成员函数：构造函数、析构函数、拷贝/移动控制
5.1 0/3/5 规则：什么时候必须自己写这四个函数
经典 C++ 里有三法则（Rule of Three）：如果你需要自己写析构函数、拷贝构造函数、拷贝赋值运算符三者中的任何一个，通常三者都需要自己写。C++11 加入移动语义后扩展到五法则，多了移动构造函数和移动赋值运算符。
之所以有这个规则，核心原因就是资源管理。当一个类自己管理堆内存（比如裸指针 new 出来的东西），系统默认生成的拷贝构造函数是浅拷贝：只拷贝指针地址，两个对象指向同一块内存。一个对象析构时释放了这块内存，另一个对象析构时再次释放同一块内存，程序崩溃。
自定义类时，最省心的做法就是用 RAII 管理资源（用 vector、string、unique_ptr 这些容器和智能指针替代裸指针），让编译器生成的默认函数自动正确。只有当你的类确实需要自己管理资源、或者需要特殊拷贝语义时，才去手写这五个函数。
在实际项目里，我看到的大部分 0/3/5 问题，本质上都是因为裸指针 + new/delete 引起的。先换成 RAII，再谈自己写特殊成员函数。
5.2 构造函数初始化列表与成员声明顺序矛盾
关于初始化顺序的坑，前面数据成员部分已经用实例说过一遍，这里再强调一下：任何成员如果在初始化列表里有值，那也是按声明顺序执行。如果成员 a 依赖 b，而 a 声明在 b 前面，就会拿到未初始化变量。规避方法很简单，按依赖关系调声明顺序，或者直接用默认值初始化成员，不让成员之间的初始化互相依赖。
5.3 拷贝赋值自赋值防护
自赋值是老生常谈的问题。例如：
cpp复制class StringHolder {
public:
StringHolder& operator=(const StringHolder& rhs) {
if (this == &rhs) return *this; // 自赋值检查
delete[] data_;
data_ = new char[rhs.len_ + 1];
copyData(rhs.data_, rhs.len_);
return *this;
}
private:
char* data_ = nullptr;
size_t len_ = 0;
};
如果没有自赋值检查，第一行 delete[] data_ 就会把自己的内存释放掉，后面 copy 时就崩了。现代 C++ 更推荐 copy-and-swap 惯用法，但这个最基础的自赋值防护还是要知道。虽然实际开发中可以使用 unique_ptr 或 string 来避免手写拷贝赋值，但面试中这类题出现频率实在太高，如果面试官追问，你至少需要把自赋值检查、深浅拷贝、异常安全说出来。
5.4 default 与 delete：精确控制特殊成员
C++11 提供了 default 和 delete，这是对类成员控制的一大进步。default 能让编译器重新生成某个特殊成员函数，哪怕你因为定义了其他构造函数导致它被隐式禁用了；delete 则能明确禁止某个函数的使用。例如：
cpp复制class NonCopyable {
public:
NonCopyable() = default;
NonCopyable(const NonCopyable&) = delete;
NonCopyable& operator=(const NonCopyable&) = delete;
};
删除拷贝操作，对管理独占资源的类非常有用。如果类里有 unique_ptr 成员，实际上编译器就会帮你隐式删除拷贝操作，所以很多时候你连写都不用写。这里延伸出一个重要区别：private + 不实现的旧式禁用方案，编译通过但链接报错，而 delete 能直接在编译期报错，错误信息也清晰。
6. 类成员相关的常见编译/链接问题排查
6.1 未定义的外部符号：静态成员没定义
把下面这个类写在头文件里，并用到了静态成员：
cpp复制class Counter {
public:
static int count_;
};
如果不加 inline static，只是在类内声明了 static int count_，那么必须在某一个 .cpp 文件里写：
cpp复制int Counter::count_ = 0;
否则链接时报未定义外部符号。C++17 后可以直接写：
cpp复制static inline int count_ = 0;
这大概是类成员中使用频率最高的一个头文件编写坑。每次报这个链接错误，第一反应应该就是检查是不是某个静态数据成员只声明没定义。
6.2 const 对象无法调用非 const 成员函数
很多人编译报错时说“不存在可以访问的默认构造函数”或者“没有匹配的成员函数”，其实根因是忘了给成员函数加 const。例如：
cpp复制const Student& s = someStudent();
std::string name = s.getName(); // 如果 getName() 非 const，这里就编译失败
解决办法不是去掉 const，而是给只读函数加上 const 限定符。这提醒我们自己写类时接口的 const 限定要准确。
6.3 继承中的名字隐藏
子类定义了一个和父类同名但不同参数的函数，会隐藏父类的同名函数，而不是重载。这个坑非常隐蔽：
cpp复制class Base {
public:
void func(int x);
};
class Derived : public Base {
public:
void func(double d); // 这里会把 Base::func 隐藏掉
};
int main() {
Derived d;
d.func(3); // 解析到 Derived::func(double)，不是 Base::func(int)
}
这属于“类成员作用域”问题：派生类成员名字会遮挡基类成员名字，跟 C++ 作用域规则一致。解决办法是把基类的同名重载用 using 引入到派生类作用域：
cpp复制class Derived : public Base {
public:
using Base::func;
void func(double d);
};
这种问题经常被归入 C++ 八股文，但其实在大型设计里很容易碰到。遇到看似调用不到原本想要的重载，优先检查是否发生了名字隐藏。
6.4 拷贝操作引发的对象切片
把派生类对象赋值给基类时，会发生切片：派生类中额外成员会被丢弃，哪怕使用了拷贝赋值也一样。例如：
cpp复制class Person { public: virtual ~Person() = default; std::string name_; };
class Student : public Person { public: int grade_; };
Student s;
Person p = s; // 切片！grade_ 被丢弃
如果确认要去掉扩展部分就用切片，但如果希望保持多态，传指针或引用。这是一个概念性坑，也经常在讨论类成员时被问到。它在实际工程里会造成不易察觉的 bug，比如把派生类对象存到 vector
7. 实战设计优化：接口最小化、const 正确性和成员组织
7.1 不要一上来就把所有 getter/setter 写满
新手的习惯经常是每个私有成员都配一个 getter 和 setter，写出来一大堆代码，看起来非常“规范”，却可能让类变成“公共数据的袋子”。正确的做法是先确定类的操作，也就是业务上你有什么需要，再确定接口。比如学生成绩系统里，需要的是“加成绩”“算平均分”“查最高分”，你就不应该把 vector 的引用直接暴露给外部，而是暴露 addScore 和 averageScore。这样未来内部如果改用数组、改用其他容器，接口可以不变，调用方完全无感。
7.2 const 正确性应该从第一行代码开始
const 正确性不是后期优化项，而是一个贯穿整个工程的规范。一旦从一开始就养成了所有不修改对象的函数都加 const 的习惯，后续调用和重构都会顺畅。如果前期没加，后期想加 const 就得把所有相关调用链都暴露出来，成本陡增。
从设计一个成员函数时就问自己三句话：
- 这个函数会不会修改成员变量？
- 如果不会，能不能加 const？
- 这个函数要不要被派生类覆写？
7.3 成员声明顺序不要乱调
尽量按照“public 接口在前面，private 实现细节后面”来写。这不仅是可读性问题，也影响默认的构造顺序。构造函数初始化列表的执行顺序实际上是数据成员的声明顺序，如果你想让自己和队友少点踩坑，成员的声明顺序就应该按照初始化的先后逻辑来排。依赖别人的成员排在后面。
数据成员声明顺序，也会影响对象的内存布局。如果想优化内存占用，把大的、对齐要求高的成员放前面，小成员放后面。它不会影响程序的可读性太多，但真的能省空间。
8. 类成员在继承与多态中的注意事项
8.1 基类析构函数必须是 virtual
如果类会被继承，请用 virtual 析构函数。这个点无论强调多少次都不嫌多。原因很简单：通过基类指针 delete 派生类时，编译器需要知道应该调用派生类析构函数。如果基类析构不是虚函数，它不会做动态绑定，直接把对象当作基类来删。派生类部分资源没有正常释放，属于未定义行为。C++11 之后可靠写法是：
cpp复制class Base {
public:
virtual ~Base() = default;
Base(const Base&) = default;
Base& operator=(const Base&) = default;
Base(Base&&) = default;
Base& operator=(Base&&) = default;
};
如果你不希望该类被继承，可以用 final 修饰类，让析构函数不需要虚。此外，一个不太广为人知的技巧是；如果类所有成员都是 RAII 对象，即便析构函数没加 virtual，很多情况下编译器也不会因为 double free 等问题崩溃，但只是碰巧没垮，并非正确。
8.2 派生类里 override 与访问权限
访问控制和虚函数是不冲突的：一个 private 的虚函数仍然可以被子类覆写，但外部无法通过子类对象指针直接调用。这种设计可以提高接口封装性，模板方法模式里有应用。需要注意，如果把基类虚函数设计成 protected 或者 private，派生类能否覆写看得是“能否访问”，不是“能否在外部调用”。
C++ 的访问检查是在静态类型阶段做的。也就是说，用基类指针时按基类访问权限检查，如果用基类指针能访问某个 public 虚函数，即使实际对象是派生类，实际被调用的函数可以是基类 private 虚函数覆盖后的版本，但通过基类指针调用仍然可行。虽然这类技巧新手用不着，但理解了这一点，对“成员可访问性”的理解会更深一层。
8.3 类型成员与作用域
类里除了数据和行为，还可以定义类型别名或嵌套类。成员类型在类外使用时需要用类名限定，比如 Student::NameList。类型成员也遵循 access 控制，private 的类型往外传递会产生很多编译错误。工程上常见的设计是“Pimpl 惯用法”，在主类里声明一个某个私有嵌套类型（Impl）的 unique_ptr 成员。这个设计把实现细节藏起来，是非常实用的一种类成员设计，值得了解。
当编译器处理一个类时，类的声明的顺序会影响可见性，所以嵌套类型一般放到前面。比如：
cpp复制class Student {
public:
using Scores = std::vector<int>;
void setScores(Scores s) { scores_ = std::move(s); }
const Scores& getScores() const { return scores_; }
private:
Scores scores_;
};
9. 新手练习与常见面试点：如何检验自己真的懂了
这里给出几个我常用的自我检验“类成员”掌握程度的思考题，都是真实编程里会碰到的：
第一，什么情况下编译器会删除类的默认拷贝构造函数？如果类里有 const 成员、引用成员或者 unique_ptr 成员，默认拷贝构造都会被删除或无法生成。能答出来这点，说明对成员的底层约束有了直觉。
第二，用户定义的构造函数会不会影响默认构造函数？只要用户定义了任何构造函数，默认构造函数就不会自动生成，除非显式 = default。上面 0/3/5 规则中，因为定义了析构函数导致拷贝操作被弃用，这类例子能说出多少条？
第三，为什么标准库里有些类的成员函数既可以是 const 又负责修改内部状态？典型的是 mutex 的 lock 本应该是 const 外面调用的吗？并不是，但 std::shared_ptr 里 use_count 是 const 的，而 reset 不是 const。可见 const 成员函数不是“绝对不能动任何东西”，mutable 提供了一种温和的后门。
第四，两个类互相包含对方的成员是否可行？如果直接作为成员，会产生无限递归；前向声明只能用于指针/引用成员，不能用于值成员。如果想要环状关系，必须使用指针或引用，并注意编译依赖。这也是类成员设计中的常见架构问题。
第五，什么时候返回引用，什么时候返回值？像 std::map::operator[] 返回引用，因为它需要支持修改，而 empty() 返回 bool，const 版本返回 bool 值。返回私有成员的引用会破坏封装，所以如果要暴露内部容器只读，返回 const 引用是一个折衷，但调用方仍然可以持有这个 const 引用，然后在另一个线程中修改对象引起悬垂。
10. 绕不开的 const 成员函数与 mutable 深入辨析
这里把 const 成员函数单独拎出来再深挖一下，因为它是很多项目里最容易忽略的接口门面。
const 修饰的是成员函数里隐式的 this 指针，使 this 的类型变成 const ClassName*。所以在这个函数中，对普通成员的赋值是禁止的，调用非 const 成员函数也不行。但有个例外：如果一个成员函数声明为 const，它返回的是成员变量的指针或引用，外部仍然可以通过这个指针或引用修改内部数据。比如：
cpp复制class Data {
public:
std::string& value() const { return value_; } // 外部可修改私有数据！
private:
std::string value_;
};
这时候 const 看起来是摆设。正确的做法通常是返回 const 引用：
cpp复制const std::string& value() const { return value_; }
如果确实要暴露可变访问，就提供非 const 重载。工程上这组重载可能产生大量重复代码。利用 C++17 的 if constexpr 写辅助模板是进阶玩艺儿，但日常项目里，我常常用一个小技巧：常量版本负责实现只读，非常量版本内部转换成常量版本后去掉引用，不过这种写法需要谨慎使用。
mutable 和 const 的关系看似矛盾，其实很一致：逻辑上不改变外部可见状态，只是内部优化。比如在一个图形系统里，const 的几何计算函数可能要缓存几个矩阵结果，那么缓存字段就必须声明 mutable。
但一个非常重要经验总结是：mutable 不是“想改就改”的通行证。如果成员变量被 mutable 修饰，在实际代码 review 里，别人一眼就能看出这里有意打破了只读限制。滥用 mutable，会让 const 正确性形同虚设。正常项目里应该很克制地用它。
11. 内存与资源视角：类成员与 RAII 的结合
现代 C++ 的核心哲学之一，是“资源获取即初始化”。类成员的资源管理，本质上取决于成员的类型：
- 值类型的成员：vector、string、map、thread、fstream 等容器/对象，它们的析构函数会帮你自动清理资源。对象生命周期结束，成员逐个析构。
- 智能指针成员：unique_ptr 表达独占所有权；shared_ptr 表达共享所有权；weak_ptr 打破环形引用。
- 裸指针成员：可以拥有资源，也可以只是观察者。但必须靠你自己写五法则或约定所有权，出错率极高，不建议默认使用。
举一个实际例子，假设一个类要管理线程池：
cpp复制class ThreadPool {
public:
// 构造，创建线程，需要自己管理生命周期
explicit ThreadPool(size_t n);
~ThreadPool();
ThreadPool(const ThreadPool&) = delete;
ThreadPool& operator=(const ThreadPool&) = delete;
void submit(std::function<void()> task);
private:
std::vector<std::thread> workers_;
std::queue<std::function<void()>> tasks_;
std::mutex m_;
std::condition_variable cv_;
bool stop_ = false;
};
这里因为 std::thread 不是可拷贝的，编译器不会生成拷贝构造和拷贝赋值，所以理论上可以省略对拷贝构造的 delete 声明。但显式 delete 有两个好处：一是能明确告诉阅读代码的人，这个类不能拷贝；二是如果加一个 std::mutex 成员，它也会使默认析构函数无法编译，这时就需要自己定义析构函数，场景更复杂。写工程时我们需要在类的行为意图上主动表达：类成员的类型已经帮你决定了“可不可以拷贝”“能不能移动”“什么时候析构”。
很多书上说“成员对象按声明顺序析构”，这跟构造是相反的。一个类里嵌套了其他类对象，析构时先执行本类自己的析构函数体，再按逆序析构各个成员。所以 constructor 里申请的资源写到别的成员里，生命周期管理最好依赖那个成员的析构，不要手动释放资源后还让成员析构再释放一次，否则 double free。
12. 类成员设计中的几个实战反馈
说几个我实际遇到的场景，不是理论，而是真实踩过的坑。
场景一：在头文件中定义了一个类，大量成员函数都写在类内，导致任何小改动都触发全工程大编译。后来把大部分函数改成类外定义，编译速度明显提升。这条对大型项目尤其重要：成员函数的定义如果不涉及模板，尽量放 .cpp 里；模板类成员实在不能放 .cpp，可以把实现放到一个 inl 文件中，然后在需要的位置显式 include，降低头文件依赖耦合。
场景二：两个类互相引用，看起来只有“你中有我我中有你”，结果编译报“使用未定义的类型”。原因是类内直接按值持有对方时，编译器需要知道对方完整定义才能计算大小。相互依赖的类，通常真正应该用到的是前向声明 + 指针/引用成员，或者把一个方向的设计变成“组合 + 回调”。
场景三：对象池或“函数对象”里大量使用 lambda，lambda 捕获字段，并赋值给 std::function 成员。这种写法很常见，但要注意：std::function 成员占用的内存是固定的，捕获太多值的 lambda，在放入对象时可构造但未必能保证无堆分配；另外如果类整体被拷贝，std::function 也会拷贝潜在的可调用状态。关于性能，可以聊得很深，不过日常最核心的提醒是：尽量避免让 std::function 捕获 this，如果这个类的生命周期小于该 std::function 的调用生命周期，会悬垂。
场景四：多线程环境里读一个类的 const 方法，如果函数内部访问共享可变状态并且没加锁，就存在数据竞争。const 只代表“不修改逻辑状态”，不代表“线程安全”。如果真的要在 const 方法里修改缓存，需要同时把对应成员声明为 mutable，并且加锁。两个概念互相配套使用时，才能既保留 const 接口，又保证线程安全。
12.1 辅助工具建议
类成员排查过程中，开发环境很关键。如果是 Windows + MSVC，经常会碰到 “visual c++ redistributable” 之类的基础运行库缺失问题，这只是部署环境问题，跟类成员语法无关。Linux 下如果出现链接未定义符号，用 nm 或 objdump 查符号时会发现命名修饰（mangled name）复杂的成员函数名。理解 ABI 符号可以用 c++filt 来还原成可读签名；看到形如 _ZN7Student8setNameERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE 这类符号，不要慌，这就是 Student::setName(std::__cxx11::basic_string const&) 的 mangled 形式，一般来自类成员函数实现和声明不一致或者静态成员未定义。
如果是在 VSCode 下调试，注意 VSCode 配置 C/C++ 环境时，需要把 IntelliSense 标准配置成跟实际编译标准一致，不然类成员判断会飘红，提示找不到定义和变量，其实很可能只是编译器版本或标准版本设错了。个人经验是 VSCode + clangd 对类成员跳转和引用重命名支持得比默认的 C/C++ 插件好；但新手如果对 CMake 还不熟，直接在官方插件里配好 include 路径，也完全够用。
13. 类模板中的特殊成员：随类型实例化而变化
最后单独聊一下模板类。类模板的成员函数只有在实例化被使用的时候才可能被编译，所以类模板的成员定义通常可以放在头文件里。但是，类模板中也存在一些隐式陷阱：
模板类的 static 数据成员比较特殊。非 const 的 static 成员模板在 C++17 之前也需要在类外定义，且定义本身要写成模板：
cpp复制template <typename T>
class MyArray {
public:
static int count_;
};
template <typename T>
int MyArray<T>::count_ = 0;
C++17 后可以直接：
cpp复制template <typename T>
class MyArray {
static inline int count_ = 0;
};
成员函数模板也是一类特殊的类成员：它可以按需对函数参数做独立于类的模板类型推导。平时最常见的应用是构造函数模板：
cpp复制class Wrapper {
public:
template <typename T>
explicit Wrapper(T&& value) : impl_(std::forward<T>(value)) {}
private:
std::string impl_;
};
这样的构造模板很容易造成构造函数被过度匹配，尤其在重载决策中抢走拷贝构造的功能，需要谨慎设计。为避免坑，可用 SFINAE 或概念约束来限制类型。
C++ 里的类成员还有析构函数、移动函数等细节，这里几乎都有表述。但最想表达的一点是：类成员并不是孤立语法，它是一组一致性的契约。数据成员决定对象状态和资源，成员函数把状态变为行为，特殊函数成员决定对象生命周期里从构造到析构、从拷贝到移动的复制/转移，访问控制决定边界。把这个四件套协同好了，你才真正会设计 C++ 类，而不仅仅是在抄语法。
我自己的工作习惯是，每写一个新类，先不写函数实现，先列出：
- 这个类有哪些成员？
- 每个成员是否应该 const？
- 这个类可不可以/应该不应该被拷贝、移动？
- 哪些函数是 public 接口，哪些只应该是 private 工具？
- 如果将来扩展，哪些成员最容易变，怎么防止这种变化波及到外部？
先把这几个问题想清楚，再在键盘上敲代码，出错率会低很多。类成员这块没有捷径，就是多切边界、多写小用例、多关注编译告警。祝顺利。