friend函数绕过访问控制，违背封装“不绕过契约操作内部状态”的本质，因跳过成员函数的校验逻辑易致对象非法状态；仅适用于operator等极少数深度耦合场景。
friend 函数绕过 private/protected 访问控制
它不是类的成员，却能直接读写类的 private 和 protected 成员——这和封装“隐藏实现细节、只暴露必要接口”的本意冲突。封装的核心不是“不让别人看到”，而是“不让你绕过契约直接操作内部状态”。friend 本质上开了个后门，且这个后门不经过任何成员函数的逻辑校验（比如边界检查、状态同步、日志记录）。
常见错误现象：friend 函数里直接修改 private 成员变量，导致对象进入非法状态，而类自身完全不知情；或者多个 friend 函数各自维护不同逻辑，彼此冲突。
- 使用场景有限：仅适用于极少数必须深度耦合的场景，比如
operator 流输出、序列化器、某些数学库的跨类运算（如 <code>Vector和Matrix的乘法） - 一旦声明为
friend，该函数就获得对整个类内部的无约束访问权，无法限制到某个字段或某段逻辑 - 类的内部变更（比如把一个
int换成std::optional<int></int>）会直接导致所有friend函数编译失败或行为异常，破坏封装带来的“内部可演进性”
friend 声明泄露类的实现细节
你在类内写 friend void serialize(const MyClass&, std::ostream&);，等于向外界宣告：“我内部有这些字段、它们是这样组织的、你得按这个结构去读”。这和把 struct 的字段全 public 没本质区别，只是语法上藏了一层。
实际影响比想象中更重：头文件里出现 friend 声明，意味着所有包含该头文件的代码都隐式依赖了那个友元函数的签名和语义。哪怕你只是改了 serialize 的参数名，所有调用方都得重新编译。
立即学习“C++免费学习笔记（深入）”；
-
friend函数通常定义在头文件外，但声明必须在类定义内——这强制把实现耦合提前暴露给所有使用者 - 无法用 pimpl 或接口抽象来隔离变化；想换序列化格式？要么改
friend函数，要么改类定义，二者必居其一 - 单元测试时容易误用：测试代码常被设为
friend来“方便”测私有逻辑，结果把测试和实现细节绑死，重构成本陡增
替代方案比 friend 更可控
真正需要的是“可控的访问”，不是“无条件的豁免”。多数情况下，加一层薄薄的公开接口就能兼顾效率与封装。
比如流输出，与其写 friend std::ostream& operator，不如提供一个 <code>to_string() 或 print_to(std::ostream&) const 成员函数：
class MyClass {
private:
int value_;
mutable std::string cache_;
public:
void print_to(std::ostream& os) const {
if (cache_.empty()) cache_ = std::to_string(value_);
os << cache_;
}
};
-
print_to是const的，能参与 const 正确性检查；friend函数默认没有 const 约束 - 可以做缓存、懒计算、线程安全包装——
friend函数做不到，因为它看不到类的 this 指针语义 - 如果真要跨类协作（如
A需要读B的内部状态），优先考虑让B提供明确的observer接口，而不是开放全部字段
friend 不是 bug，但它是架构债务的显性标记
它本身不报错、不崩溃、甚至跑得飞快。问题在于：每次你写下一个 friend，都是在说“我现在没想清楚怎么设计接口，先硬连一下”。时间一长，这些连接点就成了系统中最难解耦、最难测试、最不敢动的部分。
最容易被忽略的一点：C++ 没有 friend 作用域控制。你不能说“只允许这个 friend 读 field_a，不许碰 field_b”。权限粒度只有“全有”或“全无”。
