从值类型和引用类型的角度来回答这个问题，从苹果博客的这篇文章来看，它看起来非常简单:

使用值类型[例如struct, enum]: 用==比较实例数据是有意义的 你希望副本有独立的状态 这些数据将在代码中跨多个线程使用 在以下情况下使用引用类型[例如class]: 比较实例标识和===是有意义的 您希望创建共享的、可变的状态

正如在那篇文章中提到的，没有可写属性的类将与结构体的行为相同，但有一点需要注意:结构体最适合线程安全模型——这是现代应用程序架构中日益迫切的需求。

假设我们知道Struct是值类型，Class是引用类型。

如果你不知道值类型和引用类型是什么，那么看看按引用传递和按值传递之间的区别是什么?

根据mikeash的帖子:

... Let's look at some extreme, obvious examples first. Integers are obviously copyable. They should be value types. Network sockets can't be sensibly copied. They should be reference types. Points, as in x, y pairs, are copyable. They should be value types. A controller that represents a disk can't be sensibly copied. That should be a reference type. Some types can be copied but it may not be something you want to happen all the time. This suggests that they should be reference types. For example, a button on the screen can conceptually be copied. The copy will not be quite identical to the original. A click on the copy will not activate the original. The copy will not occupy the same location on the screen. If you pass the button around or put it into a new variable you'll probably want to refer to the original button, and you'd only want to make a copy when it's explicitly requested. That means that your button type should be a reference type. View and window controllers are a similar example. They might be copyable, conceivably, but it's almost never what you'd want to do. They should be reference types. What about model types? You might have a User type representing a user on your system, or a Crime type representing an action taken by a User. These are pretty copyable, so they should probably be value types. However, you probably want updates to a User's Crime made in one place in your program to be visible to other parts of the program. This suggests that your Users should be managed by some sort of user controller which would be a reference type. e.g struct User {} class UserController { var users: [User] func add(user: User) { ... } func remove(userNamed: String) { ... } func ... } Collections are an interesting case. These include things like arrays and dictionaries, as well as strings. Are they copyable? Obviously. Is copying something you want to happen easily and often? That's less clear. Most languages say "no" to this and make their collections reference types. This is true in Objective-C and Java and Python and JavaScript and almost every other language I can think of. (One major exception is C++ with STL collection types, but C++ is the raving lunatic of the language world which does everything strangely.) Swift said "yes," which means that types like Array and Dictionary and String are structs rather than classes. They get copied on assignment, and on passing them as parameters. This is an entirely sensible choice as long as the copy is cheap, which Swift tries very hard to accomplish. ...

我个人不会这样命名我的类。我通常将我的命名为UserManager而不是UserController，但想法是一样的

另外，当你必须重写一个函数的每个实例(即它们没有任何共享功能)时，不要使用类。

所以不是一个类的几个子类。使用几个符合协议的结构体。

使用结构体的另一种合理情况是，当你想对新旧模型进行delta/diff运算时。对于引用类型，你不能开箱即用。对于值类型，突变是不共享的。

结构比类快得多。同样，如果你需要继承，那么你必须使用Class。最重要的一点是类是引用类型，而结构是值类型。例如,

class Flight {
    var id:Int?
    var description:String?
    var destination:String?
    var airlines:String?
    init(){
        id = 100
        description = "first ever flight of Virgin Airlines"
        destination = "london"
        airlines = "Virgin Airlines"
    } 
}

struct Flight2 {
    var id:Int
    var description:String
    var destination:String
    var airlines:String  
}

现在让我们创建两者的实例。

var flightA = Flight()

var flightB = Flight2.init(id: 100, description:"first ever flight of Virgin Airlines", destination:"london" , airlines:"Virgin Airlines" )

现在让我们将这些实例传递给两个修改id、描述、目的地等的函数。

func modifyFlight(flight:Flight) -> Void {
    flight.id = 200
    flight.description = "second flight of Virgin Airlines"
    flight.destination = "new york"
    flight.airlines = "Virgin Airlines"
}

同时,

func modifyFlight2(flight2: Flight2) -> Void {
    var passedFlight = flight2
    passedFlight.id = 200
    passedFlight.description = "second flight from virgin airlines" 
}

so,

modifyFlight(flight: flightA)
modifyFlight2(flight2: flightB)

现在如果我们打印航班a的id和描述，我们得到

id = 200
description = "second flight of Virgin Airlines"

在这里，我们可以看到FlightA的id和描述被改变了，因为传递给modify方法的参数实际上指向FlightA对象(引用类型)的内存地址。

现在如果我们打印FLightB实例的id和描述，

id = 100
description = "first ever flight of Virgin Airlines"

这里我们可以看到FlightB实例没有改变，因为在modifyFlight2方法中，Flight2的实际实例是传递而不是引用(值类型)。

在Swift中，引入了一种新的编程模式，称为面向协议编程。

创建型模式:

在swift中，Struct是一种自动克隆的值类型。因此，我们可以免费获得实现原型模式所需的行为。

而类是引用类型，在赋值过程中不会自动克隆。为了实现原型模式，类必须采用NSCopying协议。

浅拷贝只复制指向那些对象的引用，而深拷贝复制对象的引用。

为每种引用类型实现深度复制已成为一项乏味的任务。如果类包含进一步的引用类型，我们必须为每个引用属性实现原型模式。然后我们需要通过实现NSCopying协议复制整个对象图。

class Contact{
  var firstName:String
  var lastName:String
  var workAddress:Address // Reference type
}

class Address{
   var street:String
   ...
} 

通过使用结构体和枚举，我们使我们的代码更简单，因为我们不需要实现复制逻辑。

结构和类之间的相似之处。

我用简单的例子来创建主旨。 https://github.com/objc-swift/swift-classes-vs-structures

和差异

1. 继承。

结构不能在swift中继承。如果你愿意

class Vehicle{
}

class Car : Vehicle{
}

参加一个培训班。

2. 经过

Swift结构按值传递，类实例按引用传递。

语境的差异

结构常量和变量

示例(用于2014年全球开发者大会)

struct Point{
 
   var x = 0.0;
   var y = 0.0;

} 

定义一个名为Point的结构体。

var point = Point(x:0.0,y:2.0)

现在如果我试着改变x，它是一个有效的表达式。

point.x = 5

但如果我定义一个点为常数。

let point = Point(x:0.0,y:2.0)
point.x = 5 //This will give compile time error.

在这种情况下，整个点是不可变常数。

如果我使用类Point代替，这是一个有效的表达式。因为在一个类中，不可变常量是对类本身的引用，而不是它的实例变量(除非那些变量定义为常量)

结构是值类型，类是引用类型

值类型比引用类型快 值类型实例在多线程环境中是安全的 多线程可以改变实例，而不必担心 关于竞争条件或死锁 与引用类型不同，值类型没有引用;因此, 就是没有内存泄漏。

在以下情况使用值类型:

你希望副本有独立的状态，数据才会被使用 跨多线程的代码

在以下情况使用引用类型:

您希望创建共享的、可变的状态。

更多的信息也可以在苹果文档中找到

https://docs.swift.org/swift-book/LanguageGuide/ClassesAndStructures.html

额外的信息

Swift值类型保存在堆栈中。在进程中，每个线程都有自己的堆栈空间，因此没有其他线程能够直接访问您的值类型。因此，没有竞争条件、锁、死锁或任何相关的线程同步复杂性。

值类型不需要动态内存分配或引用计数，这两者都是昂贵的操作。同时，值类型上的方法是静态分派的。就性能而言，这为值类型创造了巨大的优势。

作为提醒，这里有一个Swift列表

值类型:

结构体 枚举 元组 基本类型(Int, Double, Bool等) 集合(数组，字符串，字典，集合)

引用类型:

类 任何来自NSObject的东西 函数 关闭