1. 从一次编译报错说起当两个类需要“相互认识”最近在重构一个老项目的模块时遇到了一个经典的C编译错误。场景是这样的我有一个Player玩家类它需要管理一个Inventory背包对象同时Inventory类在实现某些功能时又需要知道它的所有者Player是谁以便访问玩家的某些状态比如等级、职业。很自然地我在各自的头文件里互相包含了对方的头文件。代码看起来“逻辑”上很通顺// Player.h #include Inventory.h class Player { private: Inventory inventory; // 玩家拥有一个背包 // ... 其他成员 }; // Inventory.h #include Player.h class Inventory { private: Player* owner; // 背包知道它的所有者 // ... 其他成员 };满怀信心地点击编译编译器MSVC立刻给了我一个下马威错误 C2027: 使用了未定义类型 “Player”或者“Inventory”取决于编译顺序。当时的第一反应是检查头文件守卫#ifndef是不是写错了或者路径不对。反复确认后发现包含路径没问题。这个错误的核心其实指向了C类型系统的一个基础规则在使用一个类型例如声明一个该类型的成员变量、创建对象、访问其成员之前这个类型必须是“完全定义”的而不仅仅是“声明过”的。在我这个例子中Player.h包含了Inventory.h编译器开始处理Player.h。当它看到Inventory inventory;这一行时它需要知道Inventory这个类型到底有多大占多少字节以便为Player对象分配内存。于是它跳转到Inventory.h。在Inventory.h里它又看到了Player* owner;这里它只需要知道Player是一个类型名因为指针的大小是固定的与指向的类型无关所以它继续处理。但紧接着Inventory.h又包含了Player.h……这就形成了一个循环包含的僵局。编译器在Player尚未完成定义时就被要求去确定Inventory的完整布局而Inventory的定义又依赖于Player的完整定义死锁了。这个错误的本质不是文件找不到而是类型定义的循环依赖。它揭示了在C中当两个类需要相互引用时简单地互相#include是行不通的。我们需要一种机制在其中一个类尚未完全定义时就让另一个类“知道”它的存在。这就是向前声明Forward Declaration登场的时候。2. 理解“未定义类型”错误编译器到底需要什么要解决C2027错误我们必须先理解编译器在不同上下文下对类型信息的需求。这直接决定了我们是能用简单的向前声明过关还是必须引入完整的类型定义即#include头文件。2.1 何时只需要声明向前声明足矣向前声明的基本形式是class ClassName;。它仅仅告诉编译器“ClassName是一个类类型它的定义在别处。” 在以下几种情况下仅凭向前声明就足够了声明指针或引用ClassName* ptr;或ClassName ref;。因为指针和引用在内存中本质上是地址它们的大小例如在x64系统上通常是8字节与它们指向的类型的完整细节无关。编译器不需要知道ClassName有哪些成员、占多大空间就能为指针/引用分配内存。声明函数原型参数或返回类型ClassName* createObject();或void processObject(const ClassName obj);。函数声明本身不涉及创建或操作该类型的对象只需要知道类型名。在另一个类中声明友元friend class ClassName;。在我的Player和Inventory例子中Inventory类里的Player* owner;就属于这种情况。owner是一个指针所以Inventory的头文件里其实不需要#include “Player.h”只需要一个向前声明class Player;即可。2.2 何时必须要有定义必须#include当代码需要了解类型的“内部细节”时向前声明就不管用了必须让编译器看到该类型的完整定义即其头文件内容。这包括创建该类型的对象非指针/引用ClassName obj;。编译器必须知道ClassName的构造函数、析构函数以及所有成员变量以计算obj的确切大小并在栈或全局数据区分配内存。访问类的成员变量或函数obj.memberVariable或obj.memberFunction()。编译器需要检查该成员是否存在以及访问权限public/private/protected。继承自该类class Derived : public ClassName { ... };。派生类需要知道基类的布局和虚函数表等信息。定义参数或返回类型为该类型的函数体如果涉及对象操作即使函数原型中用了指针/引用如果在函数体内解引用并访问了成员那么在定义该函数的.cpp文件中就必须包含该类型的头文件。在我的例子中Player类里的Inventory inventory;这一行就踩中了第一条红线。这里声明的是一个Inventory类型的对象值语义成员而不是指针。因此编译器在处理Player.h时必须已经完整地见过Inventory类的定义才能确定Player对象中要为inventory成员留出多少字节。注意这里有一个关键点#include是一个纯粹的文本替换指令在预处理阶段执行。循环包含会导致预处理器的无限递归通常会被编译器或预处理器以错误截断。而向前声明和类型定义的依赖关系是在编译阶段进行语义分析时才真正暴露出来的问题。3. 破解循环依赖向前声明的实战策略理解了上述原则我们就可以系统地解决Player和Inventory的相互引用问题了。核心思路是打破循环包含链用向前声明替代不必要的#include并将必须使用类型完整定义的代码推迟到源文件.cpp中。3.1 方案一将值成员改为指针或引用首选这是最常用、最清晰的解决方案。它直接消除了其中一个方向上的“必须要有定义”的依赖。修改后的头文件// Player.h // 不再直接包含 Inventory.h因为只需要 Inventory* 或 Inventory class Inventory; // 向前声明 class Player { private: Inventory* inventoryPtr; // 改为指针 // 或者 std::unique_ptrInventory inventory; // 使用智能指针更好 // 或者 Inventory inventoryRef; // 如果生命周期确保也可以用引用 public: Player(); ~Player(); void useItem(int itemId); // ... 其他成员函数其实现需要Inventory的完整定义放在Player.cpp中 }; // Inventory.h // 这里甚至不需要向前声明Player因为下面用的是Player* // 但如果后续成员函数参数用到Player等可以加class Player; #include memory // 如果需要智能指针 class Inventory { private: Player* owner; // 这里本来就是指针向前声明即可 public: explicit Inventory(Player* own) : owner(own) {} void addItem(const Item item); // ... 其他成员函数 };对应的源文件// Player.cpp #include “Player.h“ #include “Inventory.h“ // 在这里才包含Inventory的完整定义 #include “Item.h“ Player::Player() { inventoryPtr new Inventory(this); // 原始指针注意内存管理 // 更好的做法inventory std::make_uniqueInventory(this); } Player::~Player() { delete inventoryPtr; // 对应new } void Player::useItem(int itemId) { // 现在可以安全地使用inventoryPtr因为包含了Inventory.h if (inventoryPtr-hasItem(itemId)) { // ... 使用物品的逻辑 } }这个方案的优点彻底解耦头文件两个类的头文件不再相互依赖减少了编译时的耦合度。修改其中一个类的私有成员不会导致另一个类的所有引用文件重新编译。更灵活的内存管理使用指针尤其是智能指针如std::unique_ptr可以控制对象的生命周期也便于实现诸如“背包为空时延迟创建”等逻辑。符合面向对象设计表示“拥有”关系时使用指针或引用往往比内嵌对象更常见。注意事项内存管理如果使用原始指针必须在析构函数中正确释放内存并考虑拷贝构造/赋值的问题通常禁用或实现深拷贝。强烈建议使用智能指针std::unique_ptr或std::shared_ptr来避免内存泄漏。空指针检查在使用指针前尤其是在Inventory的方法里使用owner指针时要做好判空保护除非你能在构造和生命周期中绝对保证其有效性。3.2 方案二使用前置声明与指针并分离实现这个方案是方案一的细化特别强调将依赖推迟到.cpp文件。即使成员变量已经是指针如果类的成员函数声明中使用了对方类型的对象而非指针/引用也可能需要调整。假设Player有一个方法参数是Inventory对象不常见但可能// Player.h (有问题的版本) #include “Inventory.h“ // 为了避免错误似乎得包含 class Player { public: void mergeInventory(Inventory other); // 错误这里需要Inventory的完整定义 };即使mergeInventory的参数是Inventory而非Inventory或Inventory*在函数声明处就需要知道Inventory的大小用于生成调用代码的压栈指令实际上对于非引用/指针的参数传递调用者需要知道如何拷贝构造临时对象。因此头文件里仍然需要完整定义。修正方法是修改设计使用指针或引用传递// Player.h class Inventory; // 向前声明 class Player { public: void mergeInventory(const Inventory other); // 改为const引用向前声明即可 void mergeInventory(Inventory* other); // 或改为指针 };然后将函数实现放在Player.cpp中并在那里#include “Inventory.h“。3.3 方案三重新审视设计——是否真的需要双向紧密耦合有时循环依赖是一个设计上的“坏味道”。我们可以问自己几个问题Inventory是否必须持有Player*能否通过将Player的上下文信息作为参数传递给Inventory的方法Player是否必须内嵌Inventory对象能否通过接口抽象基类来访问背包功能从而解耦例如可以定义一个IInventoryOwner接口// IInventoryOwner.h class IInventoryOwner { public: virtual int getLevel() const 0; virtual ~IInventoryOwner() default; }; // Inventory.h class IInventoryOwner; // 向前声明接口 class Inventory { private: IInventoryOwner* owner; public: explicit Inventory(IInventoryOwner* own) : owner(own) {} void someMethod() { int level owner-getLevel(); // 通过接口调用 // ... } }; // Player.h #include “IInventoryOwner.h“ #include “Inventory.h“ // 现在可以安全包含了因为Inventory只依赖IInventoryOwner* class Player : public IInventoryOwner { private: std::unique_ptrInventory inventory; public: Player() : inventory(std::make_uniqueInventory(this)) {} int getLevel() const override { /* 实现 */ } };这样Inventory只依赖于一个抽象的接口而不依赖于具体的Player类耦合度大大降低。这是一个更高级、更灵活的设计模式。4. 向前声明的局限性与替代方案向前声明虽好但并非万能。除了前面提到的“必须要有定义”的场景外还有以下限制标准库类型如std::vector,std::string通常不能向前声明。因为标准库模板的实现复杂且可能依赖于特定的命名空间和内部细节。正确的做法是直接包含对应的头文件vector,string。需要在头文件中使用类的内联函数或访问静态成员如果头文件里有一个内联函数其实现中使用了另一个类的成员那么即使这个类是以指针形式出现在函数参数里在内联展开时也需要其完整定义。这时可能需要将函数改为非内联在.cpp中实现。涉及继承或typeid、dynamic_cast等RTTI操作这些都需要类型的完整定义。当向前声明无法解决问题或者代码结构确实需要两个类在头文件中彼此知晓对方的完整结构时这种情况应尽量避免可以考虑以下“终极”方案使用一个共同的“第三方”头文件来包含定义或者将相互依赖的部分抽离成第三个类。但更务实的建议是回到方案一将至少一方的依赖改为指针/引用这是C中处理循环依赖最标准、最有效的方法。5. 实战中的经验与避坑指南在我多年的C项目经验中处理这类编译错误和设计循环依赖积累了一些比教科书更实用的心得优先使用指针或智能指针而非对象成员在设计类之间的组合关系时除非有极强烈的性能需求需要内存局部性和明确的生命周期绑定否则优先考虑使用std::unique_ptr或原始指针。这不仅能避免循环包含问题也使类的职责更清晰耦合度更低。std::unique_ptr还能自动管理内存省去很多麻烦。头文件只做最小化声明养成习惯头文件里只放类声明、函数声明、必要的内联简单函数和常量。所有函数实现只要不是特别简单、确实需要内联优化的一律放到.cpp文件里。这样能最大程度减少头文件之间的依赖。使用前置声明替代不必要的#include在头文件中如果只需要用到某个类的指针或引用坚决使用向前声明class X;而不是#include “X.h“。这能显著提升编译速度尤其是对于大型项目。警惕隐式的“必须包含”场景默认参数在头文件的函数声明中如果默认参数是一个需要完整定义的类型对象也会引发问题。尽量将默认参数放在函数实现中C11起支持在函数声明和定义处分别指定默认参数但需一致。using别名或typedef如果别名指向一个需要完整定义的类型同样需要包含对应头文件。利用编译器的错误信息错误C2027通常会明确指出在哪一行、哪个文件使用了未定义的类型。首先检查这一行代码属于我们前面说的“只需要声明”还是“必须要有定义”的场景。如果是前者检查是否包含了正确的头文件或做了向前声明如果是后者就要考虑调整设计改指针或移动代码到.cpp文件。为循环依赖设计“防火墙”如果两个模块而不仅仅是两个类存在循环依赖考虑引入一个中间接口层就像上面的IInventoryOwner例子或者依赖倒置让高层模块依赖低层模块的抽象。这是软件设计层面更根本的解决之道。最后记住一个简单的检查清单当你在A.h中写了B b;对象那么A.h必须#include “B.h“。当你在A.h中写了B* bPtr;或B bRef;或void func(B b);那么A.h只需要class B;向前声明并在A.cpp中#include “B.h“。遵循这个规则可以避免绝大多数因类型未定义导致的编译错误。 C++循环依赖解决方案：向前声明与指针破解编译错误C2027
1. 从一次编译报错说起当两个类需要“相互认识”最近在重构一个老项目的模块时遇到了一个经典的C编译错误。场景是这样的我有一个Player玩家类它需要管理一个Inventory背包对象同时Inventory类在实现某些功能时又需要知道它的所有者Player是谁以便访问玩家的某些状态比如等级、职业。很自然地我在各自的头文件里互相包含了对方的头文件。代码看起来“逻辑”上很通顺// Player.h #include Inventory.h class Player { private: Inventory inventory; // 玩家拥有一个背包 // ... 其他成员 }; // Inventory.h #include Player.h class Inventory { private: Player* owner; // 背包知道它的所有者 // ... 其他成员 };满怀信心地点击编译编译器MSVC立刻给了我一个下马威错误 C2027: 使用了未定义类型 “Player”或者“Inventory”取决于编译顺序。当时的第一反应是检查头文件守卫#ifndef是不是写错了或者路径不对。反复确认后发现包含路径没问题。这个错误的核心其实指向了C类型系统的一个基础规则在使用一个类型例如声明一个该类型的成员变量、创建对象、访问其成员之前这个类型必须是“完全定义”的而不仅仅是“声明过”的。在我这个例子中Player.h包含了Inventory.h编译器开始处理Player.h。当它看到Inventory inventory;这一行时它需要知道Inventory这个类型到底有多大占多少字节以便为Player对象分配内存。于是它跳转到Inventory.h。在Inventory.h里它又看到了Player* owner;这里它只需要知道Player是一个类型名因为指针的大小是固定的与指向的类型无关所以它继续处理。但紧接着Inventory.h又包含了Player.h……这就形成了一个循环包含的僵局。编译器在Player尚未完成定义时就被要求去确定Inventory的完整布局而Inventory的定义又依赖于Player的完整定义死锁了。这个错误的本质不是文件找不到而是类型定义的循环依赖。它揭示了在C中当两个类需要相互引用时简单地互相#include是行不通的。我们需要一种机制在其中一个类尚未完全定义时就让另一个类“知道”它的存在。这就是向前声明Forward Declaration登场的时候。2. 理解“未定义类型”错误编译器到底需要什么要解决C2027错误我们必须先理解编译器在不同上下文下对类型信息的需求。这直接决定了我们是能用简单的向前声明过关还是必须引入完整的类型定义即#include头文件。2.1 何时只需要声明向前声明足矣向前声明的基本形式是class ClassName;。它仅仅告诉编译器“ClassName是一个类类型它的定义在别处。” 在以下几种情况下仅凭向前声明就足够了声明指针或引用ClassName* ptr;或ClassName ref;。因为指针和引用在内存中本质上是地址它们的大小例如在x64系统上通常是8字节与它们指向的类型的完整细节无关。编译器不需要知道ClassName有哪些成员、占多大空间就能为指针/引用分配内存。声明函数原型参数或返回类型ClassName* createObject();或void processObject(const ClassName obj);。函数声明本身不涉及创建或操作该类型的对象只需要知道类型名。在另一个类中声明友元friend class ClassName;。在我的Player和Inventory例子中Inventory类里的Player* owner;就属于这种情况。owner是一个指针所以Inventory的头文件里其实不需要#include “Player.h”只需要一个向前声明class Player;即可。2.2 何时必须要有定义必须#include当代码需要了解类型的“内部细节”时向前声明就不管用了必须让编译器看到该类型的完整定义即其头文件内容。这包括创建该类型的对象非指针/引用ClassName obj;。编译器必须知道ClassName的构造函数、析构函数以及所有成员变量以计算obj的确切大小并在栈或全局数据区分配内存。访问类的成员变量或函数obj.memberVariable或obj.memberFunction()。编译器需要检查该成员是否存在以及访问权限public/private/protected。继承自该类class Derived : public ClassName { ... };。派生类需要知道基类的布局和虚函数表等信息。定义参数或返回类型为该类型的函数体如果涉及对象操作即使函数原型中用了指针/引用如果在函数体内解引用并访问了成员那么在定义该函数的.cpp文件中就必须包含该类型的头文件。在我的例子中Player类里的Inventory inventory;这一行就踩中了第一条红线。这里声明的是一个Inventory类型的对象值语义成员而不是指针。因此编译器在处理Player.h时必须已经完整地见过Inventory类的定义才能确定Player对象中要为inventory成员留出多少字节。注意这里有一个关键点#include是一个纯粹的文本替换指令在预处理阶段执行。循环包含会导致预处理器的无限递归通常会被编译器或预处理器以错误截断。而向前声明和类型定义的依赖关系是在编译阶段进行语义分析时才真正暴露出来的问题。3. 破解循环依赖向前声明的实战策略理解了上述原则我们就可以系统地解决Player和Inventory的相互引用问题了。核心思路是打破循环包含链用向前声明替代不必要的#include并将必须使用类型完整定义的代码推迟到源文件.cpp中。3.1 方案一将值成员改为指针或引用首选这是最常用、最清晰的解决方案。它直接消除了其中一个方向上的“必须要有定义”的依赖。修改后的头文件// Player.h // 不再直接包含 Inventory.h因为只需要 Inventory* 或 Inventory class Inventory; // 向前声明 class Player { private: Inventory* inventoryPtr; // 改为指针 // 或者 std::unique_ptrInventory inventory; // 使用智能指针更好 // 或者 Inventory inventoryRef; // 如果生命周期确保也可以用引用 public: Player(); ~Player(); void useItem(int itemId); // ... 其他成员函数其实现需要Inventory的完整定义放在Player.cpp中 }; // Inventory.h // 这里甚至不需要向前声明Player因为下面用的是Player* // 但如果后续成员函数参数用到Player等可以加class Player; #include memory // 如果需要智能指针 class Inventory { private: Player* owner; // 这里本来就是指针向前声明即可 public: explicit Inventory(Player* own) : owner(own) {} void addItem(const Item item); // ... 其他成员函数 };对应的源文件// Player.cpp #include “Player.h“ #include “Inventory.h“ // 在这里才包含Inventory的完整定义 #include “Item.h“ Player::Player() { inventoryPtr new Inventory(this); // 原始指针注意内存管理 // 更好的做法inventory std::make_uniqueInventory(this); } Player::~Player() { delete inventoryPtr; // 对应new } void Player::useItem(int itemId) { // 现在可以安全地使用inventoryPtr因为包含了Inventory.h if (inventoryPtr-hasItem(itemId)) { // ... 使用物品的逻辑 } }这个方案的优点彻底解耦头文件两个类的头文件不再相互依赖减少了编译时的耦合度。修改其中一个类的私有成员不会导致另一个类的所有引用文件重新编译。更灵活的内存管理使用指针尤其是智能指针如std::unique_ptr可以控制对象的生命周期也便于实现诸如“背包为空时延迟创建”等逻辑。符合面向对象设计表示“拥有”关系时使用指针或引用往往比内嵌对象更常见。注意事项内存管理如果使用原始指针必须在析构函数中正确释放内存并考虑拷贝构造/赋值的问题通常禁用或实现深拷贝。强烈建议使用智能指针std::unique_ptr或std::shared_ptr来避免内存泄漏。空指针检查在使用指针前尤其是在Inventory的方法里使用owner指针时要做好判空保护除非你能在构造和生命周期中绝对保证其有效性。3.2 方案二使用前置声明与指针并分离实现这个方案是方案一的细化特别强调将依赖推迟到.cpp文件。即使成员变量已经是指针如果类的成员函数声明中使用了对方类型的对象而非指针/引用也可能需要调整。假设Player有一个方法参数是Inventory对象不常见但可能// Player.h (有问题的版本) #include “Inventory.h“ // 为了避免错误似乎得包含 class Player { public: void mergeInventory(Inventory other); // 错误这里需要Inventory的完整定义 };即使mergeInventory的参数是Inventory而非Inventory或Inventory*在函数声明处就需要知道Inventory的大小用于生成调用代码的压栈指令实际上对于非引用/指针的参数传递调用者需要知道如何拷贝构造临时对象。因此头文件里仍然需要完整定义。修正方法是修改设计使用指针或引用传递// Player.h class Inventory; // 向前声明 class Player { public: void mergeInventory(const Inventory other); // 改为const引用向前声明即可 void mergeInventory(Inventory* other); // 或改为指针 };然后将函数实现放在Player.cpp中并在那里#include “Inventory.h“。3.3 方案三重新审视设计——是否真的需要双向紧密耦合有时循环依赖是一个设计上的“坏味道”。我们可以问自己几个问题Inventory是否必须持有Player*能否通过将Player的上下文信息作为参数传递给Inventory的方法Player是否必须内嵌Inventory对象能否通过接口抽象基类来访问背包功能从而解耦例如可以定义一个IInventoryOwner接口// IInventoryOwner.h class IInventoryOwner { public: virtual int getLevel() const 0; virtual ~IInventoryOwner() default; }; // Inventory.h class IInventoryOwner; // 向前声明接口 class Inventory { private: IInventoryOwner* owner; public: explicit Inventory(IInventoryOwner* own) : owner(own) {} void someMethod() { int level owner-getLevel(); // 通过接口调用 // ... } }; // Player.h #include “IInventoryOwner.h“ #include “Inventory.h“ // 现在可以安全包含了因为Inventory只依赖IInventoryOwner* class Player : public IInventoryOwner { private: std::unique_ptrInventory inventory; public: Player() : inventory(std::make_uniqueInventory(this)) {} int getLevel() const override { /* 实现 */ } };这样Inventory只依赖于一个抽象的接口而不依赖于具体的Player类耦合度大大降低。这是一个更高级、更灵活的设计模式。4. 向前声明的局限性与替代方案向前声明虽好但并非万能。除了前面提到的“必须要有定义”的场景外还有以下限制标准库类型如std::vector,std::string通常不能向前声明。因为标准库模板的实现复杂且可能依赖于特定的命名空间和内部细节。正确的做法是直接包含对应的头文件vector,string。需要在头文件中使用类的内联函数或访问静态成员如果头文件里有一个内联函数其实现中使用了另一个类的成员那么即使这个类是以指针形式出现在函数参数里在内联展开时也需要其完整定义。这时可能需要将函数改为非内联在.cpp中实现。涉及继承或typeid、dynamic_cast等RTTI操作这些都需要类型的完整定义。当向前声明无法解决问题或者代码结构确实需要两个类在头文件中彼此知晓对方的完整结构时这种情况应尽量避免可以考虑以下“终极”方案使用一个共同的“第三方”头文件来包含定义或者将相互依赖的部分抽离成第三个类。但更务实的建议是回到方案一将至少一方的依赖改为指针/引用这是C中处理循环依赖最标准、最有效的方法。5. 实战中的经验与避坑指南在我多年的C项目经验中处理这类编译错误和设计循环依赖积累了一些比教科书更实用的心得优先使用指针或智能指针而非对象成员在设计类之间的组合关系时除非有极强烈的性能需求需要内存局部性和明确的生命周期绑定否则优先考虑使用std::unique_ptr或原始指针。这不仅能避免循环包含问题也使类的职责更清晰耦合度更低。std::unique_ptr还能自动管理内存省去很多麻烦。头文件只做最小化声明养成习惯头文件里只放类声明、函数声明、必要的内联简单函数和常量。所有函数实现只要不是特别简单、确实需要内联优化的一律放到.cpp文件里。这样能最大程度减少头文件之间的依赖。使用前置声明替代不必要的#include在头文件中如果只需要用到某个类的指针或引用坚决使用向前声明class X;而不是#include “X.h“。这能显著提升编译速度尤其是对于大型项目。警惕隐式的“必须包含”场景默认参数在头文件的函数声明中如果默认参数是一个需要完整定义的类型对象也会引发问题。尽量将默认参数放在函数实现中C11起支持在函数声明和定义处分别指定默认参数但需一致。using别名或typedef如果别名指向一个需要完整定义的类型同样需要包含对应头文件。利用编译器的错误信息错误C2027通常会明确指出在哪一行、哪个文件使用了未定义的类型。首先检查这一行代码属于我们前面说的“只需要声明”还是“必须要有定义”的场景。如果是前者检查是否包含了正确的头文件或做了向前声明如果是后者就要考虑调整设计改指针或移动代码到.cpp文件。为循环依赖设计“防火墙”如果两个模块而不仅仅是两个类存在循环依赖考虑引入一个中间接口层就像上面的IInventoryOwner例子或者依赖倒置让高层模块依赖低层模块的抽象。这是软件设计层面更根本的解决之道。最后记住一个简单的检查清单当你在A.h中写了B b;对象那么A.h必须#include “B.h“。当你在A.h中写了B* bPtr;或B bRef;或void func(B b);那么A.h只需要class B;向前声明并在A.cpp中#include “B.h“。遵循这个规则可以避免绝大多数因类型未定义导致的编译错误。