在OC开发里，Category（类别）、Extension（扩展）、Protocol（协议）这三样东西几乎每个项目都在用，但很多入行两三年的朋友还真说不清它们到底有什么区别。尤其是用惯了Swift之后回头写OC，很容易把extension的概念套到Category上，结果在面试或者改老代码的时候被问得一愣一愣的。这篇文章我就把自己的实际使用经验摊开来聊聊，把这三者的定义、适用场景、底层逻辑和坑一次性讲透，希望能帮你少走点弯路。
1. 为什么这三样东西值得单独拎出来讲
1.1 三者的本质定位
Objective-C是一门消息式动态语言，它的面向对象能力和C++、Java那种“类即是模板”的思路完全不同。它底层的objc_msgSend机制决定了方法调用不是直接取函数指针，而是在运行时去查方法列表，这个设计带来一个直接后果：类和类之间的关系可以被动态地、在编译期之外地调整。Category、Extension、Protocol正好分别从三个不同维度利用了这个特性。
Category是“给类加方法”，但它不需要修改原类源码，也不要求你持有这个类的源码，用它给系统类或者第三方库加方法非常顺手。Extension是“补全类私有接口”，它在编译期就把自己合并进主类，所以往里加属性、加实例变量都没问题，外界完全看不见。Protocol则是“定义对象间的方法契约”，它不关心对象是哪个类的实例，只关心“你是不是遵守了这套约定”，这和继承是两码事。
这三者表面上看都是@interface相关语法，实际上一旦你理解了它们在编译期和运行期分属不同的处理路径，很多问题比如“Category方法为什么不生效”“Extension里声明的属性为什么在外面能访问”就都能自己推导出来了。
1.2 从C/Java视角看OC的“另类设计”
如果你学过Java或者C++，再看OC会感觉有点拧巴。Java里有extends和implements，两者边界清晰：继承是为了复用代码，接口是为了统一行为。OC的Protocol类似接口，但它允许@optional，也就是有些方法对方可以不实现，调用方必须自己判断是否响应，这在Java接口里是不可想象的。
C++里给类加方法？你得用装饰器、继承或者自由函数，没有在编译期“凭空长出一个方法”的机制。OC的Category属于在运行时把方法塞进方法列表，所以它能给NSString、UIView这种最终类加方法，完全不违反类型系统。Extension则更接近C++里对“私有成员”的处理，只不过它把声明放在类内部，而不是靠private关键字。
所以学习这三样东西，不能死记语法，得从“OC到底把类型当作什么”的角度去理解：类型不是一个封闭的盒子，它是一个可以随时修饰、扩充、约束的“行为集合”。
2. 类别（Category）：给已有类做加法
2.1 类别能干什么，不能干什么
先给一个最小可用的Category示例，很多人看语法就懂了，但真正要理解的是它背后能做什么。
// NSString+MyExt.h #import <Foundation/Foundation.h> @interface NSString (MyExt) - (NSString *)oc_trimmedString; @end // NSString+MyExt.m #import "NSString+MyExt.h" @implementation NSString (MyExt) - (NSString *)oc_trimmedString { return [self stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceCharacterSet]]; } @end这个例子展示了Category最基础的能力：在不改NSString源码的情况下，给所有字符串对象添加了一个去空格的实例方法。调用方式直观，类型也没变，编译器、运行时都不会抱怨。
Category能做的事情可以列一下：
- 给已有类添加实例方法、类方法。
- 把体积很大的类按关注点拆到多个文件里，便于维护。
- 在
.m文件里用Category声明私有方法，消除“方法未声明”的警告。 - 通过关联对象（Associated Object）模拟“给类添加属性”。
- 覆盖（override）已有方法，但这个操作要非常谨慎，后面细讲。
有个关键限制必须知道：Category不能直接添加实例变量。比如你不能在Category的@interface里写@property (nonatomic, copy) NSString *name;然后期望编译器自动生成_name和getter/setter，编译器不仅不会生成，还会给你一个“property implementation must have its declaration in interface”之类的错误。解决办法有两个：一是用Extension，二是用关联对象。后面扩展部分会讲第一种，这里先说第二种。
2.2 最常用的三个场景：框架扩展、代码分区、私有方法声明
第一个场景是“给系统类补方法”。做业务开发时，NSString、NSDictionary、UIColor、UIView这些类总有些顺手的方法希望全局复用，比如判断字符串是否为空、根据RGB值创建颜色、给View加圆角，这些都属于“增强功能”。标准做法是建一个UIView+Layout之类的Category源文件，把相关代码放到一起。我习惯在方法名前加项目前缀，比如oc_，这样既表明这个是自定义补充，又能避免不同Category库（比如第三方工具库）之间方法重名冲突。
第二个场景是“大类的功能分区”。我维护过一个OrderDetailViewController，主文件曾经有3000多行，滚动找一段逻辑简直折磨人。后来按功能拆成了几个Category文件：OrderDetailViewController+TableViewDataSource、OrderDetailViewController+Network、OrderDetailViewController+Actions，主文件只保留属性声明、生命周期方法和这些Category的#import。编译后类还是同一个类，self依旧是那个控制器，但代码却清晰很多。这个拆分技巧在做大页面时非常实用。
第三个场景是“私有方法声明”。OC没有真正的私有方法，你在.m里直接写一个函数而不声明，只要在同一个作用域内调用其实也不会报错，但会有警告。更推荐的做法是在.m文件顶部用匿名Category（也就是Extension，但是很多人误叫成Category）声明一下方法，既满足了编译器，又让别人看代码时能快速建立“哪些方法是这个文件的内部实现”的预期。
2.3 类别的坑：同名方法覆盖、load与initialize、关联对象
Category并不像看上去那么“无害”，实际踩坑很多。首先必须理解同名方法覆盖问题。Category中定义的方法会插入到类方法列表的最前面，所以调用时优先命中Category版本，原类实现会被“覆盖”。更麻烦的是，如果多个Category里都定义了同名方法，调用顺序取决于文件的编译顺序，这个顺序是不确定且难以排查的。
结果就是：千万不要用Category去覆盖系统方法，尤其是dealloc、init这种生命周期方法。我见过有人为了统计页面进入次数去Category里重写viewWillAppear:，最后导致某些页面逻辑错乱，排查了整整一天，就是因为还有一个第三方库也重写了同一个方法。如果确实需要修改类的行为，优先考虑继承或方法交换（Swizzling），至少后者是显式声明“我要改变这个方法”的。
第二点是+load和+initialize。+load会在类加载时被调用，每个Category的+load都会被调用，而且调用顺序是按编译顺序来的，这个阶段类对象还没完整初始化，你如果在这里调用self的某些实例方法或者依赖其他类的+load，很容易出问题。+initialize是懒加载的，第一次给类发送消息时触发，也要注意如果多个Category和主类都实现了+initialize，最终只会执行最后一个被加载的，这也是经典的“为什么初始化逻辑只跑了一次/跑了多次”的坑。
第三点是关联对象（Associated Object）。它是在运行时给对象“挂内存”的机制。用法如下：
static char kAssociatedKey; // setter objc_setAssociatedObject(self, &kAssociatedKey, value, OBJC_ASSOCIATION_RETAIN_NONATOMIC); // getter id value = objc_getAssociatedObject(self, &kAssociatedKey);需要注意：key必须是一个在生命周期内地址稳定的指针，通常用static char变量的地址。关联对象不会自动释放，它会在宿主对象释放时被运行时清掉，但如果关联值本身有强引用，仍然要注意循环引用。另外关联对象和真正的实例变量有个重要差别：它不会参与对象复制（copy）、序列化，所以别指望靠它来保存核心业务数据。
我自己用Category时总结出一套纪律：
- Category文件名统一是“类名+功能名”。
- 方法名必须带前缀，不为了好看，单纯为了保命。
- 不在Category里重写已有的方法，除非注释里写明意图。
- 能用Extension解决的问题，不用关联对象。
3. 扩展（Extension）：类内部的“私房菜”
3.1 扩展和类别的区别
Extension的语法看起来和Category很像，区别在于括号里没有名字：
// MyClass.m #import "MyClass.h" @interface MyClass () // 这就是 Extension，外面没有名字 @property (nonatomic, copy) NSString *privateString; - (void)privateMethod; @end @implementation MyClass - (void)privateMethod { // ... } @end表面上看Extension只是“没有名字的Category”，实际上两者的性质完全不同：
- Category可以有独立的
.h和.m文件，Extension通常只在主类的.m文件里写。 - Category不能添加实例变量，Extension可以添加实例变量，并且为属性自动合成ivar和getter/setter。
- Category的方法在运行时动态加入，Extension的方法在编译期就已经成为类的一部分。
- Category可以给任何类加，Extension只针对你正在实现的那个类，脱离了主类的实现文件它毫无意义。
用一个比喻：Category像给汽车加一个外挂行李架，不影响车身结构；Extension像在车架设计图里多加一根加强筋，它本身就是整车结构的一部分。但不管怎么看，两者都是在编译运行的不同阶段把方法“并进类里”。
3.2 扩展的典型用法：私有属性、私有方法、修改只读属性
我在真实项目里用Extension最频繁的三种方式：
第一种是“私有属性”。在.h里公开的属性属于对外API，很多内部计算需要的状态不想暴露出去，直接写在Extension里：
@interface MyViewModel () @property (nonatomic, strong) NSMutableArray *cachedItems; @property (nonatomic, assign) BOOL isLoading; @end这样MyViewModel对外只有干净的两个方法声明，内部状态完全封装在实现文件里。
第二种是“私有方法声明”。很多OC开发者习惯把工具方法、事件处理方法写在@implementation内部，但为了代码清晰、也为了方法表更有结构，我会在Extension里集中声明。
第三种是“修改只读属性”。这个技巧非常实用。先在.h里声明只读属性：
// MyClass.h @interface MyClass : NSObject @property (nonatomic, readonly) NSInteger currentIndex; @end然后在.m的Extension里重新声明为可读写：
// MyClass.m @interface MyClass () @property (nonatomic, readwrite) NSInteger currentIndex; @end这样外部只能读，内部可以自由赋值，完美达到“只读对外，可写对内”的效果。搭配@synthesize或自动合成，编译器会给你生成_currentIndex和setter，没有任何额外的运行时开销。
还有一个很多人不知道的细节：Extension里是可以直接声明实例变量的，老式写法为：
@interface MyClass () { NSInteger _customCount; } @end虽然现在不常用，但如果你需要的是一个真正的变量而不是属性，这种写法依然是有效的，系统底层很多类也是这么做的。
3.3 扩展与类别的组合使用
一个新项目或者大型重构里，Extension和Category常常配合使用。我习惯的划分是：
- 公开接口：放
.h文件，顶层@interface。 - 私有接口：放
.m文件顶部的Extension，包括私有属性、私有方法、只读改读写。 - 模块化功能：放若干个Category文件，比如
MyClass+Network、MyClass+TableViewDelegate。
这样做的最大收益是“注意力隔离”。贡献者只要打开MyClass+TableViewDelegate.m就能专注处理表格相关的所有代码，主文件只负责生命周期和核心业务逻辑。同时由于所有Category都基于同一个主类，self就是那个对象，状态可以共享，不需要向Java那样为了切分一个类的职责硬造出一个“Helper”类。这种“一个类，多个实现文件”的风格是OC社区特有的，早期Cocoa框架自己就这么干，你完全不用觉得是邪道。
配合的时候有个小坑：如果对象在Extension里定义了私有属性flag，而某个Category里的方法也要访问这个属性，需要确保Category文件#import了主类的.m私有Extension吗？不需要，Category文件直接#import "MyClass.h"然后在@implementation里方法内访问self.flag其实是访问不到的，因为私有Extension声明在另一个文件里。解决办法有三个：一是把该属性放回.h（但会暴露接口）；二是把私有Extension单独抽成一个MyClass+Private.h，两边都#import；三是干脆在Category文件里只使用公开接口和方法。前两种在团队协作中都有使用，我的建议是如果Category确实需要访问内部状态，最好单独建一个MyClass+Private.h，把Extension声明放进去，这比在多个文件里重复写@interface MyClass ()要安全，否则同一个类有多个匿名Extension在编译时可能会产生重复报错。
4. 协议（Protocol）：OC里的“接口”与“委托”
4.1 协议的本质：不是继承，是约定
协议（Protocol）可以理解为一份“行为契约”。它声明了一组方法，但不实现它们。任何类只要标上<协议名>，就承诺自己实现了那些必选方法。调用方可以通过id<协议名>来持有对象，而不必关心对象的真实类型。这种弱耦合非常契合OC的“鸭子类型”思想：只要你会叫、会游，你就是鸭子。
看个最简单的协议：
@protocol Printable <NSObject> - (void)printContent; @end @interface MyModel : NSObject <Printable> @end @implementation MyModel - (void)printContent { NSLog(@"MyModel content"); } @end<NSObject>这里是协议继承协议的写法，表示任何遵循Printable协议的类也会继承NSObject协议里的那些方法，比如isEqual:、respondsToSelector:、hash等。这样做的好处是MyModel的实例在外部被使用时，对象可以确认它具备基本的NSObject行为。
协议可以多继承，比如@protocol ADelegate <NSObject, SomeOtherProtocol>，这个在委托模式中很常见。
4.2 必选与可选方法：@required与@optional
协议中默认的所有方法都是@required，不过好在编译器只会给“必选方法未实现”发警告，而不是硬错误，这也是OC和Swift不一样的地方。
如果想允许某些方法不实现，就用@optional：
@protocol TaskManagerDelegate <NSObject> @required - (void)taskManagerDidFinish:(id)manager; @optional - (void)taskManager:(id)manager didUpdateProgress:(CGFloat)progress; - (BOOL)taskManagerShouldCancel:(id)manager; @end调用可选方法之前，必须先确认目标对象是否实现了它，常用的检查是respondsToSelector:：
if ([self.delegate respondsToSelector:@selector(taskManager:didUpdateProgress:)]) { [self.delegate taskManager:self didUpdateProgress:0.6f]; }这个判断几乎成了所有delegate调用的标配，漏掉它，轻则消息无回应（nil给nil发消息没问题，但给对象发未实现的方法会崩），重则直接unrecognized selector sent to instance，线上崩溃一个晚上，很真实。
再补充一个细节：协议里也能定义属性。比如@property (nonatomic, weak) id<SomeDelegate> delegate;其实就不只是给自己用，很多时候框架会要求“遵循此协议的对象必须提供某个属性”，比如UITableViewDataSource要求实现tableView:numberOfRowsInSection:等，都属于方法契约，而@property在协议里更多是一个“约定”，是否自动合成要看实现类的写法。
4.3 协议与委托模式（Delegate）的配合
Delegate模式是协议最经典的应用，也是iOS开发里的家常便饭。核心思路是：一个对象A不直接处理所有事件，而是持有另一个对象B的弱引用，在事件发生时通知B，由B决定怎么处理。
比如一个下载器的简化版：
// Downloader.h @protocol DownloaderDelegate <NSObject> @required - (void)downloader:(Downloader *)downloader didFinishDownloadingData:(NSData *)data; @optional - (void)downloader:(Downloader *)downloader didFailWithError:(NSError *)error; @end @interface Downloader : NSObject @property (nonatomic, weak) id<DownloaderDelegate> delegate; - (void)startDownload; @end关键点就在delegate属性，必须用weak，否则很容易引入循环引用：
- 控制器强持有Downloader，Downloader强持有delegate（控制器），控制器释放不了，内存泄漏。
- 用
weak以后，控制器释放时delegate自动变nil，不会给野指针发消息。
规范且安全的delegate调用都是这个模板：
- (void)startDownload { // 模拟下载完成 if ([self.delegate respondsToSelector:@selector(downloader:didFinishDownloadingData:)]) { [self.delegate downloader:self didFinishDownloadingData:data]; } }为什么要先respondsToSelector再调用？因为delegate可能没实现可选方法，如果delegate对象是nil，向nil发消息本身也安全，但一旦delegate存在而方法未实现，就直接崩溃。在开发阶段和线上事故里，“delegate方法名少写了一个冒号”或者“delegate没实现回调”是最常见的一类崩溃。
4.4 协议在框架中的体现
OC的很多框架几乎就是靠协议撑起来的。UITableView就是典型：UITableViewDataSource负责告诉表格“有多少行、每行什么内容”，UITableViewDelegate负责“用户点了哪一行、行高多少”等交互回调。这两个协议把表格组件和业务逻辑彻底解耦，你不需要继承UITableView就能给它“喂”数据和“监听”事件。
再比如NSURLSession，每次网络请求都要指定一个NSURLSessionDelegate（或者更常见的NSURLSessionDataDelegate）来处理重定向、证书校验、数据接收等回调。再比如NSCopying协议，如果你想让自定义对象支持copyWithZone:（用于copy语义），就必须遵守它并实现方法。这些协议本质上都在说：你不用关心我的内部实现，只需要按我约好的方法签名来回应我。
实际写第三方SDK时，协议更是“对外API”的重要组成部分。让别人自己的类继承你的基类是很侵入的设计，而仅仅是让它们遵循一个协议、实现几个方法，则轻量得多。这也是我在组件化拆分时最常用的沟通方式。
5. 三者对比与面试常问
5.1 一张表看懂区别
把Category、Extension、Protocol放在一起看，差异就非常清晰了：
| 对比项 | 类别（Category） | 扩展（Extension） | 协议（Protocol） |
|---|---|---|---|
| 语法 | @interface ClassName (Name) | @interface ClassName () | @protocol Name |
| 能否新增属性 | 不能（需关联对象模拟） | 能，自动合成ivar和getter/setter | 能声明，由遵守方实现 |
| 能否新增实例变量 | 不能 | 能 | 不能（只能约定接口） |
| 能否覆盖已有方法 | 能，但风险高 | 能，需在主实现中写 | 不适用 |
| 是否需要修改原类 | 不需要，能作用于系统类 | 必须在当前类实现文件中 | 不需要，任意类可声明遵守 |
| 编译期/运行期特性 | 运行时把方法加入类 | 编译期并入主类 | 编译期类型检查为主 |
| 典型用途 | 扩展系统类、拆分大类、便捷方法 | 私有属性、私有方法、只读改读写 | 定义接口、委托回调、组件解耦 |
从这表能看出：Category最灵活但能力受限于“只有方法”；Extension最“实”，能力接近在主类里随意加东西；Protocol则根本不是修改类，而是定义一种“规格”，约束其他类来实现。
5.2 面试高频题：类别和继承怎么选？协议和类别能一起用吗？
面试里几乎必问“Category和继承怎么选”。我的回答套路是这样：
- 如果你想添加的是“行为”，而且不依赖额外状态，优先Category。比如给
UIView加一个动画效果方法，这只是个行为增强，用Category干净利落。 - 如果你要添加“状态”，也就是需要新属性、新实例变量，用继承更合适。比如一个
CircleButton，很可能它有cornerRadius、iconImage、badgeCount这些属性，这是状态，应该继承。 - 如果逻辑上确实满足“是一个”（is-a）关系，继承；如果只是“有这个能力”（has the ability），Category或协议都行。
- 继承会产生新类型，Category不会。如果接收方参数类型必须严格是
CircleButton，继承就匹配；Category只是给原类增加方法，类型名不变，没法被识别成新类型。
“协议和Category能一起用吗”也是个高频追问。能。有两个方向：
- 用Category给一个类补充遵循的能力，但不能让它凭空遵循外部协议并实现方法：你可以在Category的
@implementation里写协议方法实现，但要在主类声明处或者Category对应的@interface声明里加上<协议名>，比如：
@interface MyClass (Convenience) <MyProtocol> @end @implementation MyClass (Convenience) - (void)protocolMethod { // 在这里实现协议方法 } @end这样类就“通过Category的方式”满足了协议要求，对于组件化拆分很方便。
- 用Category来声明一组可选方法接口，形成所谓“非正式协议”（informal protocol）。这是很多老库的做法：定义一个NSObject的Category，把一组对外回调方法放进去，然后文档上说明“你只要实现这些方法即可”。但这种模式现在已经被
@optional协议取代，新代码不建议再用。
5.3 常见问题与排查技巧实录
我把自己和身边同事踩过的坑整理成一个“症状对药表”，遇到类似问题可以直接对照：
| 异常现象 | 真正原因 | 排查技巧 |
|---|---|---|
| Category里的方法根本调不到 | 分类文件没加入target，或文件名拼写错误 | 检查Build Phases里的Compile Sources，确认文件在列表里 |
| 多个Category里写了同名方法，执行的是不是你写的那个 | 方法覆盖顺序取决于编译顺序，没有保证 | 尽量避免同名方法，必须同名时用工具image查看方法列表顺序 |
在Category里声明@property后编译报错 | Category不支持自动合成ivar | 改用关联对象，或者把属性挪到Extension |
在+load里调用类实例方法导致崩溃 | +load阶段类可能未完全就绪 | 不要在+load里调实例方法，改用+initialize或用dispatch_once延迟 |
| delegate回调一直不执行 | delegate是strong造成循环引用、或没设置delegate、或delegate对象已被释放 | 检查属性修饰符，打日志确认delegate不为nil |
| Extension里声明的属性在外面也能访问 | 你可能在.h里也写了同名属性 | 检查主.h接口，私有的东西统一集中在.m |
| 在Category里覆盖系统方法后，系统行为异常 | 系统内部可能对原方法有依赖 | 能用继承/交换解决就尽量别直接覆盖 |
下面两个经验非常实用：
- 经验一：排查Category方法是否生效，可以用运行时API打印类的方法列表，看你的方法在不在里面。命令很简单：
unsigned int count; Method *methods = class_copyMethodList([NSString class], &count); for (unsigned int i = 0; i < count; i++) { NSLog(@"%@", NSStringFromSelector(method_getName(methods[i]))); } free(methods);这个方法能直观看到“这个方法是不是被加载进去了”，比瞎猜强很多。
- 经验二：对于delegate回调，习惯性的三连问：“sender delegate有没有赋值？delegate属性是不是weak？方法签名和协议里声明是不是一字不差？”最隐蔽的是第三个问题，
@method里少个冒号、大小写写错，编译器不会给你报错，因为只是“没有实现”而已。
技术上大概就这些。我个人在实际项目中最深的体感是：这三样东西基本决定了一个OC项目的架构风格。Category用得好能让你写扩展代码像写工具库一样顺手；Extension用得好能让接口设计和封装纪律清晰；Protocol用得好能让模块之间像插件一样组合。反过来，用不好就是线上崩溃和团队维护噩梦。所以别把它们当成几个语法点来背，而是当成三个不同维度的设计工具。遇到复杂场景，先问自己想表达的是“增强、私有还是约定”，再决定用哪把锤子。
