友元函数能访问类的私有成员是因为编译器在编译期为其特许访问权限，不进行访问控制检查；它非类成员、无this指针、需显式传参；友元关系不可继承和传递，声明须在类内；常用于左操作数为非类类型的运算符重载。
友元函数为什么能访问类的私有成员
因为编译器在编译阶段就为友元函数“开了后门”——它不经过访问控制检查，直接生成对私有成员的符号引用。这不是运行时绕过封装，而是编译期特许：只要声明为 friend，该函数就获得和类内成员函数同等的访问权限。
常见错误是以为友元能“继承”或“传递”：比如把一个友元函数再传给另一个类作友元，这是无效的。友元关系不具有传递性，也不被继承。
-
friend声明必须出现在类定义内部，且位置无关（public/protected/private 区域里都可） - 友元函数本身不是类的成员，没有
this指针，所有参数都需显式传入 - 若友元函数定义在类外，需提前声明（尤其涉及模板或跨文件时），否则链接时报
undefined reference
什么时候必须用友元函数而不是成员函数
典型场景是操作符重载中需要左操作数为非类类型，比如 operator 或 operator+ 的左值是 std::ostream 或内置类型时。
例如实现 std::cout ，operator 的第一个参数是 std::ostream&，不可能是 MyClass 的成员函数（成员函数隐含 this 为第一参数）。此时只能用非成员函数，并声明为友元才能读取 obj 的私有数据。
立即学习“C++免费学习笔记（深入）”；
- 流插入/提取运算符：
operator、operator>> - 对称二元运算符：如
operator+ (int, MyClass)或operator== (MyClass, MyClass)（当希望左右操作数类型顺序可互换） - 某些工厂函数或序列化辅助函数，需深度访问但又不适合暴露为 public 接口
友元类的典型误用与合理边界
友元类常被当成“内部模块解耦”的捷径，结果导致封装形同虚设。真正合理的使用场景极少：仅限于两个类构成逻辑上不可分的“一体两面”，且其中一方纯粹作为另一方的底层支撑存在。
例如 std::string 和它的私有迭代器类（实际标准库不这样实现，但教学模型中常见），或某些容器与其配套的 const_iterator 类——后者只读访问容器私有数据，不提供修改能力，且生命周期完全受控于容器。
- 友元类的所有成员函数（包括后续新增的）自动获得对目标类私有成员的完全访问权，无法按需限制
- 若只是需要部分访问，优先考虑提供受限的 public 成员函数（如
data()、size()），而非直接开友元 - 跨模块使用友元类极易引发头文件依赖爆炸，尤其当友元类定义在另一个 translation unit 中时，需确保其完整定义在友元声明前可见
友元带来的 ABI 和维护风险
友元会把函数或类绑定到目标类的私有实现细节上。一旦私有成员名、类型或布局变化，所有友元代码都可能悄无声息地编译通过但行为异常——因为它们直接读写内存偏移，而编译器不会校验这种访问是否仍合法。
比方说，你给类加了一个新私有成员在前面，导致原有私有成员地址偏移改变，而友元函数仍在旧偏移处读取，结果拿到的是垃圾值。这种 bug 极难调试。
- 单元测试很难覆盖友元路径，因为它绕过了公共接口契约
- 发布 DLL 或 so 时，友元函数若在动态库外定义，会破坏二进制兼容性（因为私有布局不属于 ABI 承诺）
- 现代 C++ 倾向用
key类技巧（如class secret_key { friend class A; secret_key() = default; };）替代粗粒度友元，把访问权限收缩到单个函数级别
友元不是封装的例外，而是封装边界的主动延展；延展多少，就得多承担多少耦合代价。真正棘手的不是语法怎么写，而是决定“谁值得被信任到能碰我的私有内存”。
