友元类声明必须写在被访问类内部，由被访问类单方面声明，仅允许访问private成员，不传递、不继承，典型用于容器与迭代器解耦，但会破坏封装性需谨慎使用。
友元类声明必须写在类内部
友元类不是“互相授予权限”，而是由被访问类单方面声明：只有在 A 类定义体内用 friend class B; 显式写出，B 才能访问 A 的私有/保护成员。外部或 B 自己的定义里加这行毫无作用。
常见错误是把友元声明放在类外、头文件别处，或者误以为继承关系能自动带来友元权限——完全不行。
- 声明位置必须紧挨着类成员（通常放在私有区上方，便于一眼识别）
- 不需要前置声明
B类，但若B定义在后，需在A前加class B;声明 - 友元关系不传递：
A是B的友元，B是C的友元，不意味A能访问C的私有成员
友元类不能访问 protected 成员（除非是派生关系）
这是最容易混淆的点：友元类可以访问 private 成员，但对 protected 成员的访问受继承链限制。如果 B 是 A 的友元，B 中的代码直接访问 A 对象的 protected 成员会编译失败。
原因在于 C++ 标准规定：protected 的访问权限检查发生在“通过派生类对象访问基类成员”的上下文中，而友元类不是派生类，它只是被授权访问 private。
立即学习“C++免费学习笔记（深入）”；
- 想让
B访问A的protected成员？只能把对应成员改为private，或提供public/protected的访问接口 - 若
B继承自A，那它天然可访问A的protected成员——但这和友元无关，是继承机制本身
友元类的典型使用场景：容器与迭代器分离设计
最合理也最常见的用途是解耦强关联类型，比如自定义容器类 MyVector 和它的迭代器 MyVectorIterator。迭代器需要直接读写容器内部的指针、size 等私有数据，但又不能把所有东西暴露为 public。
这时在 MyVector 内部加一句 friend class MyVectorIterator;，就能让迭代器安全高效地访问底层细节，同时保持封装边界清晰。
- 避免把容器内部结构全设为 public，防止外部误改破坏 invariant
- 比把所有操作都做成 public 成员函数更轻量（不用反复构造临时对象或调用开销）
- 注意：迭代器类本身仍需独立定义，友元声明只解决访问权限，不自动合成任何函数或关系
友元类带来的维护风险要手动控制
友元打破了封装性，一旦 A 的私有布局变化（比如字段重排、类型变更），所有友元类 B 都可能悄无声息地编译失败或行为异常——而且错误提示往往指向 B 的某行访问语句，而不是 A 的改动处。
- 建议只对高度内聚、生命周期绑定的类设友元，比如配套的序列化器、调试器辅助类
- 避免跨模块、跨团队的友元依赖；头文件暴露友元声明等于暴露了私有实现细节
- 若多个类都需要类似访问，优先考虑提供受控的
get_*接口，而非批量加 friend
真正难处理的从来不是语法怎么写，而是哪部分私有状态值得破例开放、以及开放之后谁来保证它不变——这得靠人盯，编译器帮不上忙。
