苹果给同一个矩形类型起NSRect和CGRect两个名字核心是历史演进跨平台兼容框架边界三重原因并非简单的重复定义。️ 历史起源两个独立框架的产物NSRect 诞生于早期的 NeXTSTEP 系统属于 Foundation/AppKit 框架是 Objective-C 生态的原生命名所有以NS为前缀的类型都源自 NeXT 时代的技术遗产。CGRect 是苹果推出 macOS 10.2 时伴随 Core GraphicsQuartz 2D 图形引擎诞生的属于纯 C 语言的图形框架类型前缀CG直接对应 Core Graphics 模块。早期32位系统中两者的内部实现并不完全一致NSRect的坐标值是float类型而CGRect在CoreGraphics中定义为更适配图形渲染的结构。 跨平台适配iOS 诞生后的统一2007年iOS发布后苹果为了让移动端图形渲染更高效在iOS生态中主推Core Graphics体系所有UIKit控件的frame/bounds都直接使用CGRect。而macOS上的AppKit生态为了兼容几十年的老代码继续保留NSRect作为对外接口类型。为了消除两边的类型差异苹果在64位系统时代直接把NSRect定义为CGRect的别名typealias NSRect CGRect底层完全合并彻底解决了跨平台的类型兼容问题。 命名规范无命名空间的妥协Objective-C 本身没有C/Java那样的命名空间机制苹果的通用解决方案就是给所有全局类型加模块前缀Foundation/AppKit 体系的所有类型统一加NS前缀如NSString、NSArray、NSRectCore Graphics 图形体系的所有类型统一加CG前缀如CGPoint、CGSize、CGRect这种双前缀设计既避免了不同框架间的命名冲突也让开发者一眼就能判断出一个类型属于哪个技术栈是Objective-C时代非常经典的命名实践。✅ 实际开发的影响现在64位全平台下两者100%等价你可以完全混用不需要任何强制转换。唯一的区别只是写macOS AppKit代码时用NSMakeRect()、NSMinX()等NS系列函数更符合老代码习惯写iOS UIKit代码时用CGRectMake()、CGRectGetMinX()等CG系列函数是行业通用规范