Objective-C：为何要在极简初始化的init方法中调用initWith方法？

这问题问得特别戳中痛点——我刚学Objective-C的时候也对着这个写法挠头半天！明明说init要做极简初始化，复杂逻辑放initWith里，为啥还要在init里调用它？其实这背后是Objective-C初始化设计的核心逻辑，咱们拆解来看：

1. 核心目的：代码复用+逻辑一致性 #

把所有复杂的初始化逻辑都收拢到一个指定初始化器（designated initializer）（也就是那个带参数的initWith方法）里，然后让init作为「便捷初始化器」调用它，本质是为了避免重复写代码，同时保证所有初始化路径的逻辑一致。

举个实际的例子：

// 便捷初始化器：init
- (instancetype)init {
    // 调用指定初始化器，传入默认参数
    self = [self initWithUsername:@"guest" password:@"123456"];
    return self;
}

// 指定初始化器：所有复杂逻辑都在这
- (instancetype)initWithUsername:(NSString *)username password:(NSString *)password {
    self = [super init];
    if (self) {
        self.username = username;
        self.password = [self encryptPassword:password];
        self.loginToken = [self generateToken];
        // 其他复杂的初始化操作，比如绑定通知、初始化子控件
    }
    return self;
}

这样不管用户调用init还是initWithUsername:password:，都会走同一个初始化流程，不会出现两种初始化方式导致的属性不一致、逻辑遗漏问题——维护的时候也只需要改指定初始化器的代码就行，不用两处都改。

2. 遵循苹果官方的初始化规范 #

苹果从一开始就推荐这种「指定初始化器+便捷初始化器」的模式。比如系统类里的UIView，init其实就是调用initWithFrame:CGRectZero；NSArray的init调用的是initWithCapacity:0。

这种模式对继承尤其友好：子类只需要重写父类的指定初始化器，就能保证所有父类的便捷初始化器（包括init）都能正确复用子类的逻辑，不会出现初始化链断裂的问题。如果每个初始化方法都写独立逻辑，子类继承时很容易漏掉某个初始化路径的重写，导致bug。

3. 所谓「隐藏行为」其实是行业约定 #

你觉得这是“隐藏本应显式的行为”，但在Objective-C开发圈子里，这是大家默认的共识——当一个类同时有init和带参数的initWith方法时，开发者默认init会调用带参数的版本，用默认值完成初始化。

反而如果init自己写一套独立逻辑，才会让其他开发者困惑：为啥两种初始化方式走不同的流程？会不会有隐藏的差异？所以这种“调用”不是隐藏，而是用约定减少认知成本。

总结来说，这种写法不是为了藏行为，而是为了让代码更健壮、更易维护，同时遵循官方和行业的统一规范。

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