Краткий ответ

Для проверки того, что две ссылки указывают на один и тот же экземпляр класса, используют оператор идентичности ===. Он проверяет именно личность объекта, а не равенство его данных.

Оператор == отвечает за логическое равенство и работает через соответствующую реализацию Equatable. Два разных экземпляра могут быть равны по содержимому, но при этом не быть идентичными.

Исторический контекст

В Swift разделены две независимые задачи: сравнение значения и проверка личности ссылочного объекта. Для структур обычно важно узнать, эквивалентны ли их данные, а для классов иногда требуется определить, идет ли речь об одном общем объекте.

Такое разделение предотвращает неоднозначность: совпадение свойств не означает, что экземпляры имеют общее состояние или один жизненный цикл. Явная проверка идентичности особенно важна для объектов, которыми управляют через ссылки.

Постановка проблемы

Если перепутать == и ===, можно ошибочно считать два разных объекта одним объектом либо, наоборот, не заметить, что разные части программы используют общий экземпляр.

Это влияет на кэширование, управление жизненным циклом, отслеживание объектов интерфейса и обнаружение повторного использования экземпляра. Дополнительный риск возникает у изменяемых классов: результат логического равенства может зависеть от текущего состояния свойств, тогда как идентичность остается характеристикой самого объекта.

Подробное решение

=== применим к экземплярам классов и возвращает true, только если обе ссылки обозначают один и тот же экземпляр. Если создать два объекта с одинаковыми свойствами, они все равно будут различными объектами.

== проверяет смысловое равенство. Для пользовательского класса нужно явно предоставить соответствие Equatable и определить правило сравнения; Swift не выводит такое равенство для произвольного класса автоматически.

final class User: Equatable {
    let id: Int

    init(id: Int) {
        self.id = id
    }

    static func == (lhs: User, rhs: User) -> Bool {
        lhs.id == rhs.id
    }
}

let first = User(id: 7)
let alias = first
let another = User(id: 7)

print(first === alias)   // true
print(first === another) // false
print(first == another)  // true

alias и first ссылаются на один объект, поэтому === возвращает true. another содержит такое же логическое значение id, поэтому он равен first через ==, но остается отдельным экземпляром.

Если равенство зависит от изменяемых свойств, объект может перестать соответствовать прежним ожиданиям после изменения состояния. При добавлении Hashable правило равенства и хеширования должно оставаться согласованным; изменение свойств, участвующих в хеше, после помещения объекта в множество или словарь может нарушить корректность поиска.

Ситуация из практики

В приложении нужно определить, является ли полученный объект пользователя тем же экземпляром, который уже отслеживает менеджер сессии. Сравнение через == по идентификатору пользователя не подходит: новый экземпляр с тем же идентификатором может быть логически равен старому, но не должен считаться тем же наблюдаемым объектом.

Вариант с == удобен для сравнения содержимого и устранения дубликатов по бизнес-правилу, но не позволяет надежно проверять общий экземпляр. Сравнение отдельных свойств без Equatable увеличивает связность и легко становится неполным при добавлении новых полей.

Выбранное решение — использовать === для проверки общего экземпляра, а == определить отдельно для бизнес-сравнения по неизменяемому идентификатору. В результате менеджер корректно отличает повторную ссылку на отслеживаемый объект от нового экземпляра, представляющего того же пользователя.

Что кандидаты часто упускают

Можно ли использовать === для структур?

Нет. === проверяет идентичность экземпляров классов, потому что классы имеют ссылочную семантику и отдельную личность объекта. У структуры нет идентичности в этом смысле: ее сравнивают как значение, если тип поддерживает Equatable, либо сравнивают отдельные свойства.

Попытка применить === к структурам указывает на неверную модель задачи. Если требуется отслеживать, что значение получено из определенного источника, нужно явно моделировать этот источник ссылочным объектом или хранить отдельный идентификатор.

Гарантирует ли одинаковый результат ==, что ссылки идентичны?

Нет. == может быть определен по одному или нескольким свойствам, поэтому два независимых экземпляра могут быть равны. Это нормальная ситуация для моделей, где экземпляры считаются эквивалентными по бизнес-идентификатору или содержимому.

Обратное утверждение тоже нельзя принимать как общее правило для произвольного плохо реализованного Equatable: разработчик задает семантику ==. Однако корректная реализация равенства должна быть рефлексивной, то есть объект обычно должен быть равен самому себе.

Что выбрать для проверки дубликатов в коллекции: === или ==?

Выбор зависит от смысла дубликата. === удаляет только повторные ссылки на один и тот же экземпляр, а == позволяет считать дубликатами разные экземпляры с одинаковыми значимыми данными.

Для бизнес-сущностей обычно используют Equatable и, при необходимости, Hashable, основывая правило на стабильном идентификаторе. Для управления жизненным циклом, наблюдением или владением объектами применяют ===, потому что в этих задачах важна именно идентичность экземпляра, а не совпадение его текущих данных.