Objective-C协议遵循时方法签名使用子类的崩溃问题与最佳实践

为什么编译器没有拦截这类签名不匹配 #

• Objective-C 基于动态消息分发的设计，方法的识别核心是方法选择子（SEL），也就是由方法名和参数冒号组成的完整字符串。只要选择子完全一致，编译器就不会因为方法标注的参数具体类型不同，判定方法存在签名冲突或者未实现。
• 你在实现中将参数类型从协议要求的UIView *改成UIStackView *，并没有改变createNewViewUsing:这个选择子的字符串，因此编译器完全无法感知到类型层面的不匹配。
• ObjC的类型标注本身只是给编译器和IDE的提示，不会参与运行时的方法绑定逻辑，这也是这类问题能绕过编译校验的核心原因。

运行时崩溃的本质 #

• 当外部按照协议约定传入基础类型UIView *实例时，你的实现方法会把这个实例隐式按UIStackView *类型处理，直接调用只有栈视图才有的arrangedSubviews方法，最终触发“无法识别的选择子”类崩溃。
• 这类问题本质是违反了类型安全的逆变规则：协议要求方法能接受所有UIView及其子类的入参，但你的实现只接受UIStackView一种特定子类，一旦传入其他子类实例就会出问题。

可落地的最佳实践 #

• 严格对齐协议定义的方法签名
  不要在协议实现中私自把参数类型从协议要求的父类改成子类。如果业务实现确实需要用到特定子类的能力，需要在方法内部做显式类型校验，再进行强转使用，正确的实现方式参考：

  // 完全匹配协议要求的方法签名
  - (void)createNewViewUsing:(UIView *)view {
      // 入参类型校验，提前拦截不符合要求的对象
      if (![view isKindOfClass:[UIStackView class]]) {
          NSAssert(NO, @"当前实现要求入参必须是UIStackView类型");
          return;
      }
      UIStackView *stackView = (UIStackView *)view;
      NSLog(@"当前入参的栈视图子视图：%@", stackView.arrangedSubviews);
  }
  

• 开启编译期严格校验
  在Xcode编译配置中开启Strict Objective-C Protocols选项，编译器会自动对协议实现的方法签名做类型兼容性校验，对参数类型不匹配的实现直接抛出编译警告或错误，从源头拦截问题。
• 设计层面隔离类型约束
  如果不同协议遵循类对入参有不同的类型要求，不要直接在协议中写死通用参数类型，可以通过泛型关联类型的方式，给不同实现指定对应的入参类型，避免跨实现的类型误用。
• 协作层面的规则约束
  在团队代码规范中明确要求：协议实现的方法签名必须和协议定义严格一致，禁止私自调整参数类型；代码评审时将协议方法签名校验作为固定检查项，避免人为疏漏。

常见的类型安全认知误区 #

• 很多开发者会混淆协变和逆变的适用场景：在ObjC的协议实现规则中，返回值支持协变（实现方法的返回值是协议返回值类型的子类是合法且安全的），但参数要求是逆变（实现方法的参数类型必须是协议定义参数类型的父类，才是类型安全的）。
• 把参数类型从父类改成子类的写法，本质是缩小了方法的可接受入参范围，完全违背了协议对调用方的承诺：协议告诉所有调用方“我这个方法可以接收所有UIView类型的实例”，但你的实现实际上只接收栈视图，自然会出问题。

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