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

Нет. В стандартном случае обычная async-функция, не помеченная @MainActor и не изолированная другим глобальным актором, не становится изолированной MainActor только из-за места вызова. После await она может выполняться вне главного актора, а код вызывающего метода после возврата снова проверяется в контексте MainActor.

@MainActor
func updateScreen() async {
    let value = await calculate()
    print(value)
}

func calculate() async -> Int {
    await Task.yield()
    return 42
}

Здесь updateScreen изолирован MainActor, но calculate — нет. Если вычислению нужен главный актор, это должно быть явно отражено в объявлении функции.

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

В традиционной модели выполнения вызов функции часто связывался с текущим потоком, поэтому код мог неявно продолжать работу в UI-контексте. Swift Concurrency разделяет понятия задачи, актора и потока, чтобы изоляция данных задавалась декларативно и проверялась компилятором.

Такой подход предотвращает случайное распространение UI-изоляции на весь стек вызовов. Функция получает доступ к состоянию актора только тогда, когда это предусмотрено её собственной изоляцией или явным переходом к нужному актору.

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

Метод MainActor обычно изменяет состояние пользовательского интерфейса. Если вызываемая им обычная async-функция ошибочно считается автоматически изолированной тем же актором, разработчик может ожидать выполнения тяжёлой работы на главном акторе или, наоборот, рассчитывать на доступ к UI-состоянию внутри не изолированной функции.

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

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

Изоляция определяется объявлением функции, а не тем, кто её вызвал. @MainActor у метода updateScreen гарантирует, что его изолированные участки выполняются в контексте главного актора. Но объявленная отдельно calculate остаётся не изолированной, если для неё не задан @MainActor или другой механизм изоляции.

При вызове calculate задача может приостановиться, а её продолжение планируется в соответствии с правилами не изолированной async-функции. Она не обязана выполняться на главном потоке и не получает права читать или изменять состояние MainActor без явного перехода к нему.

После завершения calculate выполнение updateScreen продолжается в его исходном изолированном контексте. Поэтому обновление UI после await допустимо, а вычислительная функция не должна напрямую обращаться к изолированному состоянию экрана.

Это отличается от создания Task внутри метода MainActor: такая задача может наследовать контекст родителя, включая акторную изоляцию. Наследование контекста задачи и изоляция вызываемой async-функции — разные механизмы, их нельзя смешивать.

Если функция действительно должна выполняться на главном акторе, её следует явно объявить изолированной MainActor. Если она выполняет независимые вычисления или ввод-вывод, обычно лучше оставить её не изолированной и передавать ей значения, безопасные для передачи между задачами.

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

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

Экран загрузки вызывает дорогое преобразование большого ответа сервера. Команда оставляет преобразование обычной async-функцией и обновляет состояние экрана только в MainActor-изолированном методе.

Вариант с пометкой всего преобразования @MainActor прост, но переносит работу в UI-контекст и может ухудшить отзывчивость интерфейса. Вариант с ручным созданием отдельной detached-задачи сложнее: появляются дополнительные требования к Sendable, отмене и обработке ошибок.

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

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

Обязан ли обычный async-код продолжаться на том же потоке, где был вызван?

Нет. Поток не является контрактом async-функции. После приостановки задача может продолжиться на другом потоке; важны акторная изоляция и корректность передачи данных, а не идентичность потока.

Достаточно ли вызвать await, чтобы получить доступ к состоянию MainActor?

Нет. await обозначает потенциальную границу приостановки и перехода исполнения, но не предоставляет произвольной функции доступ к изолированному состоянию. Для такого доступа нужен вызов из подходящего изолированного контекста или явный переход, например через MainActor.

Если обычная async-функция вызвана из MainActor, может ли она случайно блокировать интерфейс?

Да, если внутри неё выполняется длительная синхронная работа без приостановок. Отсутствие изоляции MainActor не превращает любой код автоматически в фоновую операцию с гарантией отдельного потока; планирование потоков не следует использовать как замену асинхронной архитектуре. Тяжёлую работу нужно организовать так, чтобы она не блокировала исполнитель UI, а границы изоляции и требования Sendable оставались корректными.