公开接口泄露内部状态本质是public成员（如非const变量、裸指针/引用返回）绕过类控制逻辑直接读写受保护数据，属设计缺陷，需人工审查与代码约束识别。
公开接口泄露内部状态，本质是 public 成员（尤其是可修改的成员变量或返回裸指针/引用的函数）让调用方绕过类的控制逻辑，直接读写本该受保护的数据。这不是编译错误，而是设计缺陷，必须靠人工审查 + 代码约束来发现。
看 public 成员变量是否直接暴露可变数据
只要类里有 public 的非 const 基本类型、指针、引用或容器成员，就极可能泄露状态。比如 balance、buffer、config_map 这类名字出现在 public: 下，基本等于把锁打开交给别人配钥匙。
- 检查所有
public:块下的非静态成员变量，确认它们是否都声明为const或仅用于只读场景 - 特别警惕
std::vector<t>&</t>、T*、std::string&这类返回非常量引用/指针的public函数——调用方能直接改内部缓冲区 - 如果必须提供访问，优先用
const T& get_x() const或T copy_x() const，而不是T& x()
查 getter/setter 是否破坏封装契约
看似安全的 get_foo() 和 set_bar() 也可能泄露状态，关键看它是否跳过校验、绕过依赖更新或暴露了不该暴露的粒度。
- 检查
set_函数是否做完整校验（如负值余额是否被拒绝）、是否触发关联状态更新（如修改max_size后是否重分配缓冲区） - 检查
get_返回的是副本、const 引用，还是内部结构的非常量视图（例如返回std::map<k>::iterator</k>就属于高危） - 避免 “伪封装”：比如
public: std::shared_ptr<impl> pimpl;</impl>——这等于把整个实现细节全交出去
识别 friend 声明是否过度开放
friend 是合法后门，但每处声明都要回答一个问题：“这个友元函数/类，是否必须知道我所有的私有细节，还是只需某个特定能力？”
- 检查每个
friend声明是否对应一个明确、窄接口需求（如仅需访问serialize_to()，而非整个private:区域） - 优先用
friend void serialize(const MyClass&, Stream&)这种具体函数声明，而不是friend class Serializer这种宽泛类声明 - 若
friend函数在头文件中定义（而非仅声明），说明它已获得完全访问权——此时应确认该函数是否真的需要读写所有私有成员
验证头文件暴露范围是否超出接口契约
头文件是公开接口的“法律文本”。如果 log.h 里包含了 log_internal.h，或者把 struct Impl 定义和 private: 成员一起塞进头文件，外部就能基于这些实现细节编码，一旦你重构内部结构，所有使用者都会崩。
- 确保对外头文件（如
log.h）只包含稳定接口：函数声明、public类成员、必要类型别名 - 把
private成员类型、辅助结构体、宏定义、#include实现依赖，全部移到*_internal.h或源文件中 - 使用 pimpl 模式时，
class MyClass { /* ... */ private: struct Impl; std::unique_ptr<impl> pimpl_; };</impl>中的Impl必须只在 .cpp 文件里定义
最难察觉的泄露，往往藏在“看起来很合理”的 const 引用返回和“只是帮个小忙”的 friend 里。每次加一个 public 成员或 friend 声明前，先问自己：这个访问权，是否能让外部绕过我类里任何一处状态检查、生命周期管理或一致性维护逻辑？
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
