我同意Yannick的观点。你的大胆陈述是不正确的。一个无主引用 * 必须 * 在它的生命周期内有效。在-Ounchecked程序中，未能维护这个前提是未定义的行为。我不是说“它崩溃”。我的意思是它不是一个格式良好的程序;它的作用是未定义的。一个弱引用不会因为它的发布而产生未定义的行为，即使在-Ounchecked下。
使用unowned是程序员声明引用在其整个生命周期内有效。这甚至不是Type!Assert的。!类型只是Assert引用在其被访问时有效。这就是为什么你不能在无主的上测试x == nil。它不是可选的。它不是“伪装的可选”（如Type!）。它必须始终有效。
但是，与弱引用不同的是，当其他示例具有相同的生存期或更长的生存期时，将使用无主引用。无主引用应始终具有值。-- * The Swift Programming Language(https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html) *
因此，对于你的“最深可能哲学”来说，unowned包含了一个在weak中不存在的前提条件，这个前提条件存在于程序之外，必须由程序员而不是编译器来证明，以确保一个格式良好的程序。
对于是否有理由使用unowned，如果我们采取绝对的立场（如你的问题），肯定有理由。在已知前提条件为真的情况下，它是最严格的类型。weak是比unowned弱的类型;好的类型理论鼓励我们使用最强的（限制性最强的;最少的法律的值）类型，并且unowned是比weak更强的类型。
在一个非绝对主义者（“实际”）意义上，选择更强类型的结果是代码更简单。每次使用它时都必须不断地重新Assert它不是nil的前提条件，并处理它是nil的情况（可能插入fatalError，这只是重新创建了unowned，需要做更多的工作）。使用unowned可以Assert这个前提一次。更正确的代码。我从来没有为了速度而使用unowned。我总是用它来避免在代码中一遍又一遍地回答“但是如果它是nil呢？”

粗体句子不正确。
Weak是可选的，可以随时设置。
Unowned是非可选的，但可以为nil。如果发生这种情况，您调用它，您的应用将崩溃。必须在初始化期间设置它。
另一个区别是性能，正如作者所说。Unowned不做任何检查，比weak稍微快一点。
它更好地显示了类之间的关系。
您可以查看此SO问题以了解更多详细信息：What is the difference between a weak reference and an unowned reference?

来自swift文件
“Swift还提供了不安全的无主引用，用于您需要禁用运行时安全检查的情况-例如，出于性能原因。与所有不安全操作一样，您负责检查代码的安全性。
您可以通过写入unowned（unsafe）来指示不安全的无主引用。如果您试图在一个不安全的无主引用所引用的示例被释放后访问它，您的程序将试图访问该示例曾经所在的内存位置，这是一个不安全的操作。
看起来只有当您使用unowned（不安全）来精确地表示，并且默认情况下我们使用unowed（安全）时，性能才会提高。
This is from one of the answer
无主的（safe）是一个非所有者引用，在访问时Assert对象仍然是活动的。它有点像一个弱的可选引用，每次访问时都用x！隐式地展开。unowned（unsafe）类似于ARC中的__unsafe_unretained-它是一个非所有者引用，但没有运行时检查来确定对象在访问时是否仍然有效，因此悬空引用将进入垃圾内存。unowned当前始终是unowned（安全）的同义词，但其目的是当运行时检查被禁用时，它将在-Ofast构建中被优化为unowned（不安全）。