这是一个示例场景，其中我们需要@class。

考虑一下，如果您希望在头文件中创建一个协议，该协议的参数具有相同类的数据类型，那么您可以使用@class。请记住，您也可以单独声明协议，这只是一个示例。

// DroneSearchField.h

#import <UIKit/UIKit.h>
@class DroneSearchField;
@protocol DroneSearchFieldDelegate<UITextFieldDelegate>
@optional
- (void)DroneTextFieldButtonClicked:(DroneSearchField *)textField;
@end
@interface DroneSearchField : UITextField
@end

当我发展的时候，我脑中只有三件事，这三件事从来不会给我带来任何问题。

导入超类 导入父类(当您有子类和父类时) 在项目外部导入类(比如在框架和库中)

对于所有其他类(我的项目中的子类和子类)，我通过forward-class声明它们。

如果需要，在头文件中使用前向声明，并为在实现中使用的任何类导入头文件。换句话说，您总是#import您在实现中使用的文件，如果您需要在头文件中引用一个类，也可以使用forward声明。

例外的是，你应该在头文件中导入一个类或正式协议(在这种情况下，你不需要在实现中导入它)。

我看到很多“这样做”，但我没有看到任何“为什么”的答案。

那么:为什么在头文件中使用@class，而在实现中使用#import呢?一直使用@class和#import会使你的工作加倍。除非你使用继承。在这种情况下，您将为单个@class #import多次。然后，如果您突然决定不再需要访问某个声明，您必须记得从多个不同的文件中删除。

由于#import的性质，多次导入同一个文件不是问题。 编译性能也不是真正的问题。如果是的话，我们就不会在几乎每个头文件中都使用#importing Cocoa/Cocoa.h之类的代码了。

如果你看到这个警告:

警告:接收端MyCoolClass是转发类，对应的@interface可能不存在

您需要#导入文件，但是您可以在实现文件(.m)中这样做，并在头文件中使用@class声明。

@class并不(通常)消除#import文件的需要，它只是把需求移到更接近信息有用的地方。

例如

如果你说@class MyCoolClass，编译器知道它可能会看到类似这样的东西:

MyCoolClass *myObject;

除了MyCoolClass是一个有效的类之外，它不需要担心其他任何事情，并且它应该为指向它的指针保留空间(实际上，只是一个指针)。因此，在头文件中，@class占据了90%的时间。

然而，如果你需要创建或访问myObject的成员，你需要让编译器知道这些方法是什么。在这一点上(大概在你的实现文件中)，你需要#import "MyCoolClass.h"，告诉编译器除了"这是一个类"之外的其他信息。

可以把@class看作是告诉编译器“相信我，这是存在的”。

可以把#import看作是复制-粘贴。

出于多种原因，您希望最小化导入的数量。在没有任何研究的情况下，首先想到的是它减少了编译时间。

注意，当从类继承时，不能简单地使用前向声明。您需要导入文件，以便您声明的类知道它是如何定义的。