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

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

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

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

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

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

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

Обратная ситуация также возможна: один и тот же объект сравнивается сам с собой через ===, даже если его содержимое не участвует в определении равенства. Неверный выбор оператора может привести к ошибкам в кэшировании, управлении делегатами и проверке владения объектом.

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

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

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

final class User: Equatable {
    let id: Int
    let name: String

    init(id: Int, name: String) {
        self.id = id
        self.name = name
    }

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

let first = User(id: 1, name: "Анна")
let second = User(id: 1, name: "Анна")
let alias = first

print(first == second)   // true: одинаковое состояние
print(first === second)  // false: разные экземпляры
print(first === alias)   // true: одна идентичность

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

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

В приложении есть кэш изображений, который передаётся между несколькими компонентами. Нужно проверить, используют ли компоненты один и тот же кэш, а не просто кэши с одинаковыми настройками.

Сравнение через == потребовало бы определить содержательное равенство и могло бы вернуть true для двух независимых кэшей. Сравнение ключевых свойств также ненадёжно: оно не подтверждает общность хранилища и синхронизации.

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

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

Можно ли использовать == для любого класса?

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

Гарантирует ли first == second совпадение всех свойств объектов?

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

Можно ли заменить === сравнением адресов объектов?

Нет, это было бы ненадёжным и лишним решением. Swift предоставляет === как типобезопасную проверку идентичности экземпляров класса; ручное извлечение или сравнение адресов привносит зависимости от деталей реализации и не является обычным способом выразить это намерение.