头文件互相#include不违法但易致类型不完整或重定义；解耦需前置声明+实现后移：仅当用指针/引用时可用class B;，且实现须移至.cpp中，否则智能指针等仍需完整类型。

直接结论：头文件互相 #include 不是语法错误，但会导致编译器看到不完整类型或重复定义，典型报错是 'X' does not name a type 或 redefinition of 'class X'。解耦核心就两条——前置声明 + 实现后移。

用 class B; 替代 #include "B.h" 的适用边界

前置声明只在“不需知道 B 内存布局”的场景安全：

• 成员变量只能是 B*、B&、std::unique_ptr<B>、std::shared_ptr<B> —— 这些不依赖 sizeof(B)
• 函数参数/返回值必须是 B* 或 B&；写成 B 值类型会立刻触发编译失败
• 不能用于继承（class A : public B {}）、不能用于 std::vector<B>、不能用于 class A { B b; };
• class B; 必须放在头文件最顶部，且不能被其他 #include 挡在后面（否则可能被意外污染）

为什么必须把实现挪到 .cpp 文件里

头文件里只留声明，实现全进 .cpp，才能真正切断依赖链：

• A.h 中删掉 #include "B.h"，只写 class B; 和 void foo(B* b);
• A.cpp 开头加 #include "B.h"，再实现 foo() —— 此时编译单元才真正“看见” B 的完整定义
• 若函数是 inline 或模板（如 operator[]），不能拆；此时要么重构接口，要么改用 PIMPL
• 所有构造/析构/拷贝/移动操作中若涉及 B 的完整类型（比如调用 B() 或 sizeof(B)），都必须在 .cpp 里完成

智能指针和模板的隐含陷阱

你以为写了 std::unique_ptr<B> 就万事大吉？其实它只对声明友好，对使用很挑剔：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

立即学习“C++免费学习笔记（深入）”；

• std::unique_ptr<B> ptr_; 可以放心写在头文件里（只依赖前向声明）
• 但 ptr_ = std::make_unique<B>(); 这行代码必须进 .cpp，否则编译器仍要看到 B 的完整定义
• std::vector<B>、std::array<B, 5>、std::function<void(B)> 全部要求 B 是完整类型，头文件里不能出现
• std::weak_ptr<B> 声明安全，但调用 lock() 后若立即用其返回的 std::shared_ptr<B> 构造对象，也得确保 B.h 已包含

检查 #pragma once 或 include guard 是否真生效

别以为加了防护就高枕无忧，失效常发生在这些地方：

• 同一头文件被不同路径引入（如 "A.h" 和 "../inc/A.h"），#pragma once 可能判为两个文件
• 旧版 MinGW 或某些嵌入式工具链对 #pragma once 支持不稳，建议与 #ifndef A_H 共存作双重保险
• include guard 宏名拼错（如 A_HH 写成 A_H）、漏写 #define、或宏名不是全局唯一（多个模块都用 COMMON_H）
• 头文件里定义了非 inline 函数或全局变量，即使有防护，链接阶段仍会报 multiple definition

最容易被忽略的是：你改完了前置声明，却在头文件里悄悄写了 list.push_back(std::make_unique<B>()); —— 这行代码本身就会让整个解耦努力归零。