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

Метод с пометкой nonisolated выполняется вне изоляции данного actor, поэтому он не имеет прямого доступа к его изменяемому изолированному состоянию. Такое обращение должно быть отклонено компилятором; снятие требования await не означает снятие проверки безопасности данных.

nonisolated подходит только для логики, которая не зависит от actor-изолированных свойств, либо работает с состоянием, явно доступным вне actor и безопасным для совместного использования.

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

Модель actors появилась в Swift Concurrency для защиты изменяемого состояния без ручной синхронизации через блокировки. По умолчанию методы и свойства actor изолированы: доступ к ним из другого контекста может потребовать асинхронного перехода к actor.

Однако не каждый метод объекта действительно использует его защищаемое состояние. Для чистых вычислений, метаданных или совместимых с синхронным API операций был введён механизм nonisolated, позволяющий явно объявить, что конкретное объявление не требует изоляции actor.

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

Если nonisolated-метод читает или изменяет состояние actor, возникает противоречие: вызывающий код получает синхронный доступ, тогда как состояние должно обслуживаться через изолированный исполнитель actor. Несколько вызовов могут выполняться конкурентно с изолированными методами, и обычная логика actor уже не гарантирует согласованность данных.

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

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

У actor каждое обычное изменяемое свойство и каждый обычный метод по умолчанию изолированы. Вызов из внешнего контекста передаёт выполнение на actor и потому обычно является потенциально приостанавливающимся.

Пометка nonisolated меняет это правило для конкретного объявления: оно становится доступным без ожидания actor и не выполняется в его изолированном контексте. Взамен объявление не может напрямую использовать изолированные свойства или вызывать изолированные методы как синхронные операции.

Допустимы операции над собственными параметрами, локальными значениями и состоянием, которое само объявлено доступным вне изоляции. Например:

actor Cache {
    private var values: [String: Data] = [:]
    nonisolated let subsystem = "images"

    nonisolated func subsystemName() -> String {
        subsystem
    }

    func value(for key: String) -> Data? {
        values[key]
    }
}

Метод subsystemName не обращается к values, поэтому его можно вызвать синхронно. Если добавить в него чтение values, компилятор потребует изолированный доступ через обычный метод actor.

nonisolated не превращает изменяемое состояние в безопасное для общего доступа и не является аналогом блокировки. Если метод всё-таки должен работать с состоянием actor, правильнее оставить его изолированным; если нужна независимая вычислительная часть, её можно вынести в отдельную чистую функцию или структуру.

Асинхронный nonisolated-метод может явно обратиться к изолированному API через асинхронный вызов и await. После такой точки ожидания он уже подчиняется обычным правилам конкурентности, включая возможность изменения состояния actor до возобновления метода.

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

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

Рассматривались два варианта. Первый — оставить метод nonisolated и обойти ограничение через небезопасное разделяемое состояние: это сохраняет синхронный интерфейс, но создаёт гонку и усложняет доказательство корректности. Второй — оставить имя подсистемы nonisolated, а статистику получать отдельным изолированным методом: вызов требует await, зато доступ к состоянию остаётся последовательным относительно других операций actor.

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

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

Можно ли из nonisolated-метода вызвать обычный метод того же actor без await?

Нет. Обычный метод actor изолирован, а nonisolated-метод не находится внутри этой изоляции. Такой вызов должен перейти к actor и потому выполняется как асинхронный вызов с await; синхронное обращение компилятор отклонит.
Почему добавление await не делает чтение состояния безопасным в синхронном смысле?

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

Само объявление nonisolated не делает ссылочный объект потокобезопасным. Если получатель и actor могут одновременно изменять один экземпляр, безопасность должна обеспечиваться его собственной синхронизацией или ограничениями Sendable; иначе остаётся гонка данных. Практически предпочтительнее возвращать неизменяемую копию или значение, соответствующее Sendable, а не разделять изменяемую ссылку.