private是编译期强制约束，在符号解析和访问控制检查阶段即报错，如“'age' is private within this context”，不生成目标文件；其设计旨在保障类内部实现自由变更而不破坏调用方。
因为 private 是编译期强制约束，不是运行时检查——main() 函数在语法解析阶段就被编译器判定为“类外部作用域”，任何直接访问（如 obj.private_var）都会触发错误，根本不会生成机器码。
编译器在哪儿拦你？
当你写 person.age = 25; 且 age 是 private 成员时，编译器在「符号解析」和「访问控制检查」阶段就报错，典型提示是：error: 'age' is private within this context。这不是链接失败，也不是段错误，而是连目标文件都出不来。
- 这个检查发生在 AST（抽象语法树）构建之后、代码生成之前
- 即使该成员在内存中真实存在、布局完全可知，语法上不合法就直接终止
- 和 C 的 struct 成员访问完全不同：C 没有访问控制语义，而 C++ 把
private当作语言级契约
为什么 friend 可以绕过？
friend 不是“破解”封装，而是显式授权——它让编译器在访问检查时对特定函数或类放行。比如把 main() 声明为友元（虽不推荐），编译器就会在检查 main 内部的 obj.private_member 时跳过私有性判断。
- 友元声明必须出现在类定义内部，且只能由类自身决定
- 友元关系不可继承、不可传递、不具备对称性
- 常见合理用法是友元函数做 I/O 流重载（
operator<<），而不是给main()开后门
那些看似“绕过”的操作为什么危险？
比如用 reinterpret_cast<char*>(&obj) + offsetof(...) 强行读取私有成员地址，本质是依赖标准布局类型（standard-layout）的内存偏移，但：
立即学习“C++免费学习笔记（深入）”；
- 一旦类含虚函数、多重继承、非 public 非 static 数据成员，就不再是标准布局 →
offsetof行为未定义 - 编译器优化（如字段重排、空基类优化）可能让偏移值在不同编译条件下变化
- Clang/GCC/MSVC 对未定义行为的处理策略不同，同一份代码可能在一个平台跑通、另一个平台崩溃或静默出错
真正该关注的不是“怎么突破”，而是“为什么设计成这样”：私有成员的不可见性，是为了让类能自由变更内部实现（比如把 int age 换成 std::chrono::system_clock::time_point birth_time），而不破坏所有调用方。强行穿透，等于主动放弃这一保障。
