Swift类开头直接初始化属性是否为不良实践？两种声明方式有何区别？

算力阿峰

2026-10-16

类属性初始化相关问题解答

为什么类开头直接初始化属性被认为是不良实践？

直接在类属性声明处初始化，主要有以下几个问题：

强耦合，无法做依赖注入：直接在类内部初始化依赖类，会让当前类和依赖类的具体实现完全绑定，后续如果要替换依赖实现（比如单元测试时替换为Mock实例）完全无法实现，代码可测试性极差。
初始化时机不合理：类属性的默认初始化会早于当前类自身的初始化流程执行，如果属性初始化逻辑依赖当前类的其他属性、方法，或是和当前类的生命周期强相关（比如iOS中UIViewController关联的视图），很容易出现初始化顺序错误，甚至导致崩溃。
不必要的资源浪费：如果属性只在特定业务路径下才会被使用，提前初始化会占用无意义的内存和CPU资源，尤其当依赖类初始化逻辑较重时，影响更明显。

该做法的负面影响会随着项目复杂度提升逐步显现：小项目可能暂时看不出问题，大型项目迭代时会出现改不动、单元测试写不了、隐藏崩溃多的问题。

class SomeClass {
    var someView = SomeView()
    var someViewModel = SomeViewModel() 
}

这种写法下属性是非可选类型，只要类完成初始化，属性一定有值，不需要处理解包逻辑，但缺点就是前面提到的强绑定、无法自定义传入、初始化时机不可控。

class SomeClass {
    var someView: SomeView! 
    var someViewModel: SomeViewModel?
}

这种写法只是声明了属性的类型，没有做初始化，你可以在类初始化完成之后的合适时机（比如UIViewController的viewDidLoad、自定义构造函数里）再给属性赋值，灵活性更高：

没有绝对最优的写法，根据场景选择即可：

如果是无副作用、不依赖外部参数、不需要替换实现的轻量属性（比如var count = 0这种简单值类型），直接在声明处初始化没问题，代码更简洁。
如果属性是类的核心依赖，需要支持外部传入做依赖注入，优先用非可选的普通属性，在构造函数里接收外部参数赋值，比如：
```
class SomeClass {
    let someViewModel: SomeViewModel
    init(viewModel: SomeViewModel) {
        self.someViewModel = viewModel
    }
}
```
这种写法既保证了属性非空，又支持依赖注入，是最推荐的依赖声明方式。
如果属性初始化依赖当前类的其他属性/生命周期（比如UI相关控件需要用到父视图尺寸），优先用普通可选声明，推迟到合适的时机再初始化；只有你完全确认赋值时机不会出错的场景（比如系统自动赋值的IBOutlet）再用隐式解包可选。

平时开发可以养成几个习惯：

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