头文件互相#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、std::shared_ptr—— 这些不依赖sizeof(B) - 函数参数/返回值必须是
B*或B&；写成B值类型会立刻触发编译失败 - 不能用于继承（
class A : public B {}）、不能用于std::vector、不能用于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 就万事大吉？其实它只对声明友好，对使用很挑剔：
-
std::unique_ptr ptr_;可以放心写在头文件里（只依赖前向声明） - 但
ptr_ = std::make_unique();这行代码必须进.cpp，否则编译器仍要看到B的完整定义 -
std::vector、std::array、std::function全部要求B是完整类型，头文件里不能出现 -
std::weak_ptr声明安全，但调用lock()后若立即用其返回的std::shared_ptr构造对象，也得确保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()); —— 这行代码本身就会让整个解耦努力归零。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
