基本上，你试图在Swift只允许非nil值的地方使用nil值，通过告诉编译器信任你，那里永远不会有nil值，从而允许你的应用程序编译。

有几种情况会导致这种致命错误:

forced unwraps: let user = someVariable! If someVariable is nil, then you'll get a crash. By doing a force unwrap you moved the nil check responsibility from the compiler to you, basically by doing a forced unwrap you're guaranteeing to the compiler that you'll never have nil values there. And guess what it happens if somehow a nil value ends in in someVariable? Solution? Use optional binding (aka if-let), do the variable processing there: if user = someVariable { // do your stuff } forced (down)casts: let myRectangle = someShape as! Rectangle Here by force casting you tell the compiler to no longer worry, as you'll always have a Rectangle instance there. And as long as that holds, you don't have to worry. The problems start when you or your colleagues from the project start circulating non-rectangle values. Solution? Use optional binding (aka if-let), do the variable processing there: if let myRectangle = someShape as? Rectangle { // yay, I have a rectangle } Implicitly unwrapped optionals. Let's assume you have the following class definition: class User { var name: String! init() { name = "(unnamed)" } func nicerName() { return "Mr/Ms " + name } } Now, if no-one messes up with the name property by setting it to nil, then it works as expected, however if User is initialized from a JSON that lacks the name key, then you get the fatal error when trying to use the property. Solution? Don't use them :) Unless you're 102% sure that the property will always have a non-nil value by the time it needs to be used. In most cases converting to an optional or non-optional will work. Making it non-optional will also result in the compiler helping you by telling the code paths you missed giving a value to that property Unconnected, or not yet connected, outlets. This is a particular case of scenario #3. Basically you have some XIB-loaded class that you want to use. class SignInViewController: UIViewController { @IBOutlet var emailTextField: UITextField! } Now if you missed connecting the outlet from the XIB editor, then the app will crash as soon as you'll want to use the outlet. Solution? Make sure all outlets are connected. Or use the ? operator on them: emailTextField?.text = "my@email.com". Or declare the outlet as optional, though in this case the compiler will force you to unwrap it all over the code. Values coming from Objective-C, and that don't have nullability annotations. Let's assume we have the following Objective-C class: @interface MyUser: NSObject @property NSString *name; @end Now if no nullability annotations are specified (either explicitly or via NS_ASSUME_NONNULL_BEGIN/NS_ASSUME_NONNULL_END), then the name property will be imported in Swift as String! (an IUO - implicitly unwrapped optional). As soon as some swift code will want to use the value, it will crash if name is nil. Solution? Add nullability annotations to your Objective-C code. Beware though, the Objective-C compiler is a little bit permissive when it comes to nullability, you might end up with nil values, even if you explicitly marked them as nonnull.

This is because you are trying to use a value which can possible be nil, but you decided you don't want to have to check it, but instead assume its set when you uses it and define it as !, there are different philosophies on use of variable set as force unwrap, some people are against there use at all, I personal think they are ok for things that will crash all the time and are simple to reason about, usually references to resource, like outlets to xib files, or uses of images with you app that are part of your assets, if these are not set up properly, you app is going to crash straight away, for a very obvious reason, you can get into difficult when the order of objects being created can be uncertain, and trying to reason solutions to this can be difficult, it usually means a bad design as even it you make them optional, calls to you optional variable may not ever be executed, some projects can demand use of force unwraps for security reasons, things like banking apps, because they want the app to crash rather then continue to work in an unplanned way.

基本上，你试图在Swift只允许非nil值的地方使用nil值，通过告诉编译器信任你，那里永远不会有nil值，从而允许你的应用程序编译。

有几种情况会导致这种致命错误:

forced unwraps: let user = someVariable! If someVariable is nil, then you'll get a crash. By doing a force unwrap you moved the nil check responsibility from the compiler to you, basically by doing a forced unwrap you're guaranteeing to the compiler that you'll never have nil values there. And guess what it happens if somehow a nil value ends in in someVariable? Solution? Use optional binding (aka if-let), do the variable processing there: if user = someVariable { // do your stuff } forced (down)casts: let myRectangle = someShape as! Rectangle Here by force casting you tell the compiler to no longer worry, as you'll always have a Rectangle instance there. And as long as that holds, you don't have to worry. The problems start when you or your colleagues from the project start circulating non-rectangle values. Solution? Use optional binding (aka if-let), do the variable processing there: if let myRectangle = someShape as? Rectangle { // yay, I have a rectangle } Implicitly unwrapped optionals. Let's assume you have the following class definition: class User { var name: String! init() { name = "(unnamed)" } func nicerName() { return "Mr/Ms " + name } } Now, if no-one messes up with the name property by setting it to nil, then it works as expected, however if User is initialized from a JSON that lacks the name key, then you get the fatal error when trying to use the property. Solution? Don't use them :) Unless you're 102% sure that the property will always have a non-nil value by the time it needs to be used. In most cases converting to an optional or non-optional will work. Making it non-optional will also result in the compiler helping you by telling the code paths you missed giving a value to that property Unconnected, or not yet connected, outlets. This is a particular case of scenario #3. Basically you have some XIB-loaded class that you want to use. class SignInViewController: UIViewController { @IBOutlet var emailTextField: UITextField! } Now if you missed connecting the outlet from the XIB editor, then the app will crash as soon as you'll want to use the outlet. Solution? Make sure all outlets are connected. Or use the ? operator on them: emailTextField?.text = "my@email.com". Or declare the outlet as optional, though in this case the compiler will force you to unwrap it all over the code. Values coming from Objective-C, and that don't have nullability annotations. Let's assume we have the following Objective-C class: @interface MyUser: NSObject @property NSString *name; @end Now if no nullability annotations are specified (either explicitly or via NS_ASSUME_NONNULL_BEGIN/NS_ASSUME_NONNULL_END), then the name property will be imported in Swift as String! (an IUO - implicitly unwrapped optional). As soon as some swift code will want to use the value, it will crash if name is nil. Solution? Add nullability annotations to your Objective-C code. Beware though, the Objective-C compiler is a little bit permissive when it comes to nullability, you might end up with nil values, even if you explicitly marked them as nonnull.

这是一个更重要的注释，这就是为什么隐式打开可选选项在调试nil值时可能具有欺骗性。

考虑下面的代码: 它编译时没有错误/警告:

c1.address.city = c3.address.city

然而在运行时，它给出以下错误:致命错误:在打开可选值时意外地发现nil

你能告诉我哪个对象是nil吗?

你不能!

完整的代码是:

class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()

        var c1 = NormalContact()
        let c3 = BadContact()

        c1.address.city = c3.address.city // compiler hides the truth from you and then you sudden get a crash
    }
}

struct NormalContact {
    var address : Address = Address(city: "defaultCity")
}

struct BadContact {
    var address : Address!
}

struct Address {
    var city : String
}

长话短说，使用var地址:地址!您隐藏了变量可以为nil的可能性，不让其他读取器看到。当它崩溃的时候，你会想“搞什么鬼?!”我的地址不是可选的，所以我为什么要崩溃?!

因此，最好这样写:

c1.address.city = c2.address!.city  // ERROR:  Fatal error: Unexpectedly found nil while unwrapping an Optional value 

你能告诉我哪个对象是nil吗?

这一次，代码对您来说更清楚了。您可以合理地认为，可能是强行打开了address参数。

完整的代码是:

class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()

        var c1 = NormalContact()
        let c2 = GoodContact()

        c1.address.city = c2.address!.city
        c1.address.city = c2.address?.city // not compile-able. No deceiving by the compiler
        c1.address.city = c2.address.city // not compile-able. No deceiving by the compiler
        if let city = c2.address?.city {  // safest approach. But that's not what I'm talking about here. 
            c1.address.city = city
        }

    }
}

struct NormalContact {
    var address : Address = Address(city: "defaultCity")
}

struct GoodContact {
    var address : Address?
}

struct Address {
    var city : String
}

如果在CollectionView中出现此错误，请尝试创建CustomCell文件和Custom xib。

在mainVC的ViewDidLoad()中添加此代码。

    let nib = UINib(nibName: "CustomnibName", bundle: nil)
    self.collectionView.register(nib, forCellWithReuseIdentifier: "cell")

因为上面的答案清楚地解释了如何安全地玩可选项目。 我将试着解释什么是可选的真正在迅速。

声明可选变量的另一种方法是

在 ： 可选<Int>

和可选类型只是一个枚举与两种情况，即

 enum Optional<Wrapped> : ExpressibleByNilLiteral {
    case none 
    case some(Wrapped)
    .
    .
    .
}

将nil赋值给变量i。我们可以 var i =可选<Int>.无 或者为了赋值，我们会传递一些值 var i =可选<Int>.some(28)

根据swift， 'nil'是没有值。 为了创建一个用nil初始化的实例，我们必须遵守一个叫做expressiblebynillliteral的协议，如果你猜到了，很好，只有optional符合expressiblebynillliteral，不鼓励符合其他类型。

expressiblebynilleral有一个叫做init(nilleral:)的方法，它用nil初始化实例。你通常不会调用这个方法，根据swift文档，不建议直接调用这个初始化式，因为每当你初始化一个可选类型时，编译器都会调用它，用nil文字。

就连我自己也不得不(没有双关语的意思)把我的脑袋绕在可选科目上:D 快快乐乐。