从编译器的角度来看，这三种后缀并不是简单的“分类标签”，而是告诉编译器应该用哪种“语言模式”来解析代码的指令。
Objective-C 的编译器（现主流为 Clang）是一个多面手，它会根据后缀名切换不同的语法解析引擎。
1. .h (Header File)
本质：声明书（Interface）
- 角色： 它不参与最终的编译产物生成，只是被
.m或.mm文件#import（或#include）进去。 - 内容： 放置
@interface、常量定义、函数原型等。 - 注意： 虽然
.h内部可以写 Objective-C 代码，但它本身是中性的。如果一个 C 语言文件#include了一个包含 Obj-C 语法的.h，编译器会报错。
2. .m (Implementation File)
本质：Objective-C 的标准实现文件
- 语法模式： 允许 C + Objective-C。
- 编译逻辑： 编译器会启用 Obj-C 的运行时特性（如消息传递），同时保留对标准 C 语法（如指针、结构体）的支持。
- 局限性： 如果你在
.m中写 C++ 的类（class）或模板（template），编译器会因不识别这些语法而报错。
3. .mm (Objective-C++ File)
本质：三种语言的“混血儿”
- 语法模式： 允许 C + Objective-C + C++ 。
- 核心用途： 当你需要调用 C++ 编写的库（例如 OpenCV、FFmpeg 或跨平台的底层自研引擎）时，必须使用
.mm文件。 - 底层机制： 编译器会同时开启 Obj-C 和 C++ 的解析器。你可以在一个 Obj-C 类的方法实现里，直接实例化一个 C++ 对象。
核心区别对比表
| 特性 | .h | .m | .mm |
|---|---|---|---|
| 语言支持 | 取决于包含它的文件 | C, Objective-C | C, Objective-C, C++ |
| 编译速度 | 不直接编译 | 快 | 慢（因为要加载 C++ 复杂的符号表） |
| 常见用途 | 接口、宏定义、协议声明 | 业务逻辑、UI 实现 | 接入 C++ 库、高性能算法 |
| 命名习惯 | Header | Message / Method | Message-Message (Obj-C++) |
避坑指南
- 不要为了“以防万一”把所有文件都改成
.mm：C++ 的引入会显著增加编译时间，并可能导致命名空间冲突（例如 C++ 的Complex和某些 C 库的定义冲突）。 - 封装原则： 好的架构通常会在
.mm内部处理 C++ 逻辑，而在其对应的.h中只暴露标准的 Obj-C 接口。这样外部引用该.h的文件就不必全部变成.mm，从而减少编译负担。
