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

@unchecked Sendable не добавляет синхронизацию и не делает тип безопасным автоматически. Разработчик вручную гарантирует, что экземпляры типа можно безопасно передавать между конкурентными контекстами; если гарантия неверна, возможна гонка данных.

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

Модель конкурентности Swift использует Sendable, actors и проверку изоляции, чтобы выявлять небезопасную передачу данных на этапе компиляции. Это решает распространённую проблему старых моделей с общим изменяемым состоянием, где корректность зависела только от дисциплины разработчика.

@unchecked Sendable появился как escape hatch для случаев, когда компилятор не способен доказать безопасность, но разработчик может обеспечить её сам. Такой механизм нужен для интеграции с существующими потокобезопасными типами и низкоуровневыми примитивами, однако он переносит ответственность с компилятора на человека.

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

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

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

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

@unchecked Sendable означает только: тип принудительно считается соответствующим Sendable. Это не блокировка, не очередь, не actor и не проверка атомарности операций.

Например, следующий тип формально можно передавать между задачами, хотя его состояние не защищено:

final class Counter: @unchecked Sendable {
    var value = 0
}

let counter = Counter()
Task.detached { counter.value += 1 }
Task.detached { counter.value += 1 }

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

Безопасная реализация должна защищать всё изменяемое состояние одним согласованным механизмом. В зависимости от задачи это может быть actor, mutex или другой корректно используемый примитив синхронизации. Защищать только отдельные поля недостаточно, если несколько полей должны изменяться согласованно.

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

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

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

Команда переносит кеш из старого многопоточного модуля в Swift Concurrency. Класс кеша использует внутреннюю блокировку, но компилятор не может распознать эту гарантию, поэтому разработчики добавляют @unchecked Sendable.

Вариант с простым объявлением соответствия имеет плюс: миграция проходит быстро. Минус — компилятор перестаёт защищать код от будущего добавления незащищенного свойства или метода.

Вариант с actor делает безопасность очевидной и проверяемой, но меняет вызовы на асинхронные и может потребовать адаптации API. Вариант с mutex сохраняет синхронный интерфейс, однако требует документировать правила блокировки и не допускать доступа к внутренним данным в обход неё.

Рациональное решение — оставить @unchecked Sendable только у тщательно проверенного низкоуровневого класса с закрытым состоянием и централизованной блокировкой. Для нового кеша с асинхронными операциями выбрать actor. Это сохраняет совместимость там, где она необходима, и не распространяет ручную гарантию на незащищенные типы.

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

Достаточно ли сделать ссылку на объект неизменяемой через let, чтобы получить потокобезопасность?

Нет. let запрещает заменить саму ссылку, но не делает изменяемое состояние объекта неизменяемым. Объект класса всё ещё может менять свои свойства. Безопасность возможна, если объект действительно глубоко неизменяем и все связанные с ним данные также не допускают небезопасной мутации.
Почему безопасные отдельно взятые операции не гарантируют безопасность составной операции?

Два защищённых чтения и записи не обязательно образуют одну атомарную транзакцию. Между чтением и записью другая задача может изменить состояние. Для операции чтение—изменение—запись нужен единый критический участок или метод actor, который сохраняет нужную последовательность без промежуточного await.
Можно ли заменить @unchecked Sendable на @Sendable у замыкания и считать проблему решённой?

Нет. @Sendable проверяет, какие значения замыкание захватывает и как их можно передавать между конкурентными контекстами, но не делает захваченное ссылочное состояние потокобезопасным. Если замыкание захватывает общий изменяемый объект, сам объект всё равно должен быть immutable, изолирован actor или защищён синхронизацией.