私有成员必须显式用 private: 声明，类中首个访问控制符前的区域默认为 private，但后续未重新指定则沿用最近的访问级别；封装重在暴露接口、隐藏实现，而非盲目设 private 加 getter/setter；struct 默认 public，适合纯数据；友元虽破坏封装但必要时不可替代。
私有成员必须用 private: 显式声明
不是靠命名约定（比如加下划线），也不是靠编译器自动推断——C++ 里没有“默认私有”这回事。类里不写访问控制符，第一个成员前的区域是 private: 的，但一旦写了 public: 或 protected:，后续没再切回 private:，那后面所有成员就按当前访问级别走。
常见错误现象：class A { int x; void f(); public: void g(); }; —— 这里 x 和 f() 确实是私有的，但很多人误以为 f() 因为在 public: 后面所以也是 public，结果调用时报错 ‘f’ is inaccessible。
- 显式写
private:，哪怕只有一行成员，也别省 - 多个访问区之间用空行隔开，避免视觉混淆
- 构造函数、析构函数如果不想被外部调用，也要放进
private:（比如单例）
封装 ≠ 全部成员都设为 private
封装的核心是“暴露接口，隐藏实现”，不是把所有东西锁死。强行把所有字段设为 private，又只提供一堆 get_x()/set_x()，反而破坏封装——等于把内部状态完全摊开，还多了一层函数调用开销。
使用场景：当你需要约束赋值逻辑（比如检查范围）、触发副作用（比如通知更新）、或未来可能替换存储方式时，才值得用 getter/setter；否则直接暴露 public 成员更轻量、更易读、更易内联。
立即学习“C++免费学习笔记（深入）”；
-
struct默认public，适合纯数据载体（如Point { double x, y; }） -
class默认private，适合需要行为约束的类型 - 别为了“看起来封装”而封装：一个
private int age;+int get_age() const { return age; }+void set_age(int a) { age = a; }就是典型反模式
友元破坏封装但有时不可替代
当两个类深度耦合（比如容器和它的迭代器），或需要重载操作符（如 operator）且必须访问私有成员时，<code>friend 是唯一合法出口。但它不是后门，而是显式授权——你得亲手写 friend class Iterator; 或 friend std::ostream& operator。
容易踩的坑：friend 声明放在类内，但定义写在类外，结果链接时报 undefined reference to operator；或者误以为 <code>friend 能继承——它不能，子类不会自动获得父类友元权限。
- 友元函数定义尽量放在类定义外，避免头文件膨胀
- 优先用成员函数实现逻辑，仅当必须访问多个类的私有成员时才用友元类
-
friend不影响访问控制层级：友元函数仍受private/protected影响，只是它被豁免了
const 成员函数和 mutable 是封装的配套机制
标记 const 的成员函数承诺不修改对象逻辑状态，这是接口契约的一部分。但有些操作（比如缓存计算结果、统计调用次数）确实要改某个字段，又不想破坏 const 正确性——这时 mutable 就是为此而生的。
性能影响：现代编译器对 const 成员函数有更好优化机会（比如确定无副作用，可安全重排）；mutable 字段则需谨慎，滥用会导致看似 const 实际可变，引发多线程问题或违反逻辑不变量。
- 所有只读接口都应标记
const，否则无法被const对象调用 -
mutable只能用于真正不影响对象“逻辑状态”的字段（如缓存、互斥量） - 别用
mutable绕过设计缺陷：如果发现大量 const 函数都要改某个字段，说明这个字段本就不该属于该类的状态
封装的难点从来不在语法上——private: 一行就能写完。难的是判断哪些该藏、哪些该露、藏到什么程度。一个字段是否私有，最终取决于它变化时会不会牵连外部代码，而不是它“看起来是不是实现细节”。
