为何Module B中BaseViewController的internal扩展init被跨模块调用？

1. Swift模块符号可见性的实际表现 #

你认为internal权限的方法仅Module B内部可见，但当主App同时依赖Module B和Module C时，主App的编译环境会将所有依赖模块的internal符号暴露给整个App的编译单元。也就是说，在主App的上下文里，Module B中给BaseViewController添加的扩展方法，对Module C的代码是可见的——这是因为App作为顶层模块，会把所有依赖模块的符号合并到自己的命名空间中。

2. 便利初始化器的查找与继承逻辑 #

MySuperViewController没有定义任何初始化器，按照Swift规则，它会自动继承父类BaseViewController的所有指定初始化器，但你调用的init()是便利初始化器。当执行MySuperViewController()时，Swift的方法查找流程是：

• 先查找MySuperViewController自身有没有匹配的初始化器
• 找不到则向上查找父类BaseViewController的所有可用初始化器（包括扩展中声明的）
• 由于主App环境中Module B的扩展方法可见，所以会匹配到那个internal convenience init()，而非UIViewController的默认初始化器

3. 同签名扩展方法的优先级问题 #

你在Module C中给BaseViewController添加了相同签名的便利初始化器，但仍调用Module B的版本，原因是Swift中，当多个模块对同一类型添加同签名的扩展方法时，编译器会优先选择编译顺序靠前的模块中的实现。如果Module B在App的依赖顺序中先于Module C被编译，它的扩展方法就会被优先匹配。

• 明确指定子类初始化器：在MySuperViewController中显式声明你需要的初始化器，让调用时优先匹配子类自身的实现：

  class MySuperViewController: BaseViewController {
      convenience init() {
          self.init(nibName: nil, bundle: nil)
      }
  }
  

• 缩小扩展方法作用域：将Module B中的初始化器权限改为fileprivate，彻底避免被外部模块访问：

  extension BaseViewController {
      fileprivate convenience init() {
          self.init(nibName: String(describing: type(of: self)), bundle: .moduleA)
      }
  }
  

• 调整编译顺序（不推荐）：在App项目设置中将Module C的编译顺序提前到Module B之前，让Module C的扩展方法优先被匹配，但这种依赖编译顺序的代码维护性极差。

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