CLLocationManagerDelegate为何存在重复的locationManager方法声明？

Swift和Objective-C体系里，判断两个方法是不是重名，从来不是只看方法最开头的字段，而是看包含所有参数标签、参数类型的完整函数签名。你看到的两个以locationManager开头的方法，本质是完全独立的两个方法，根本不存在命名冲突。

两种代理命名风格的区别 #

苹果官方的代理方法有两种很常见的命名范式，你现在碰到的正好是两种范式的典型案例：

• UITextFieldDelegate用的是第一种：把具体触发事件的语义直接拼在代理源对象的名字后面，组成完整方法名，第一个参数就是触发事件的控件实例，不给这个参数设单独的外部标签。比如textFieldShouldReturn(_:)、textFieldShouldEndEditing(_:)，方法名直接说清了触发场景，视觉上看每个方法名都不一样。
• CLLocationManagerDelegate用的是第二种，也是苹果早期框架更通用的范式：所有属于该类的代理方法，统一用代理源类名的小写开头作为第一个参数的外部标签，第一个参数固定传触发事件的源实例，后面跟着的参数标签才用来区分具体是什么事件。

所谓“同名”的底层逻辑 #

把两个CLLocationManager的代理方法完整签名放一起对比就很清楚了：

// 位置更新回调
func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation])
// 定位失败回调
func locationManager(_ manager: CLLocationManager, didFailWithError error: Error)

这两个方法除了第一个参数的标签一样，第二个参数的外部标签、参数类型完全不同，属于Swift语法里合法的函数重载，编译器能100%准确识别你实现的是哪个回调，不会有任何冲突。
这种设计不是为了写代码好看，是有实际用处的：如果你的控制器里同时持有好几个CLLocationManager实例——比如一个管持续用户定位，一个管地理围栏区域监测——你完全可以给所有manager把代理设成同一个控制器，在回调里判断传入的manager是哪个实例，对应走不同的处理逻辑就行，省了很多重复代码。
另外这种写法是Objective-C时代的遗留习惯：Objective-C里方法的调用标识是多段拼接的选择子，上面两个方法在OC里的选择子分别是locationManager:didUpdateLocations:和locationManager:didFailWithError:，从根上就是两个完全不一样的方法。Swift和OC是无缝互通的，桥接这些系统框架的时候直接保留了原本的命名结构，才会让你产生“两个方法重名”的错觉。

内容的提问来源于stack exchange，提问作者mikstravaganza