Как продолжается выполнение кода после получения ответа от асинхронного запроса в C#?

Слушай, объясняю на пальцах, как эта асинхронная магия работает, а то у многих мозг набекрень встаёт, когда видят await.

Представь, ты на кухне ставишь чайник — это твоя асинхронная задача. Вместо того чтобы тупо пялиться на него и ждать, пока закипит (это был бы синхронный, блокирующий вызов), ты идёшь и режешь бутерброды. Чайник в это время тихонько себе греется. Как только он начинает свистеть — ты сразу возвращаешься к нему, чтобы снять его с плиты. Вот await — это и есть момент, когда ты услышал свист и вернулся к чайнику. Поток-то твой (ты на кухне) не стоял столбом, он делал другую полезную работу.

А теперь по-взрослому, но без занудства:

Когда компилятор видит await перед незавершённой таской, он делает гениальную, но в общем-то простую вещь. Он как бы ставит закладку в твоём методе и говорит: "Ладно, дружище, иди пока погуляй, освободи поток. Как эта штука (таска) сделает своё грязное дело — я тебя сразу позову обратно, прямо на эту самую строчку, и мы продолжим".

Под капотом он для этого генерит целый конечный автомат — этакую машину состояний, которая помнит, на каком моменте ты остановился и какие там переменные были. Не забивай этим голову, просто знай, что магия есть.

Смотри на живом примере, чтобы вообще всё встало на свои места:

public async Task<string> СходитьНаПочтуИНакричатьAsync()
{
    Console.WriteLine("1. Выхожу из дома, иду к почте...");
    // ТУТ МОМЕНТ ИСТИНЫ. Ждём, пока на почте выдадут посылку.
    // Поток (это я) не стоит в очереди! Я мог бы пойти купить семечек.
    string посылка = await почтальон.ВыдатьПосылкуAsync("Накладная 123");

    // !!! ВНИМАНИЕ! Сюда мы попадём ТОЛЬКО когда посылку уже получим.
    // В UI-приложении это будет тот же самый UI-поток (удобно, можно кнопки тыкать).
    // В консольном или веб-приложении — скорее всего, просто какой-то свободный поток из пула.
    Console.WriteLine("2. Ура, посылка в руках! Открываю...");

    string содержимое = ОсмотретьИНакричать(посылка); // Обычный синхронный метод.
    Console.WriteLine("3. Оказалось, это просто счёт за ЖКХ. Кричать не буду.");

    return содержимое;
}

// А вот как этим пользуемся:
public async Task ВечернийРитуал()
{
    var задачаПосылки = СходитьНаПочтуИНакричатьAsync(); // Запустили процесс!
    Console.WriteLine("Пока посылка идёт, можно зайти в магазин за хлебом...");
    КупитьХлеб(); // Эта работа идёт ПАРАЛЛЕЛЬНО с ожиданием посылки!

    // Теперь хотим получить результат.
    string итог = await задачаПосылки; // Тут тоже можем подождать, если посылка ещё в пути.
    Console.WriteLine("4. Финал: " + итог + " И хлеб есть. Жизнь удалась.");
}

Главные грабли, на которые все наступают:

• Не делай .Result или .Wait() в асинхронном мире, особенно если ты в UI (WPF, WinForms) или в ASP.NET Core! Это как взять и пригвоздить себя к стене, пока чайник кипит. С высокой вероятностью получишь взаимную блокировку (deadlock), и всё просто повиснет. Серьёзно, не надо так. Только await.
• ConfigureAwait(false) — твой друг в библиотечном коде. Это как сказать: "Мне похуй, в каком потоке продолжать работу, дай любой свободный". Это убирает лишние переключения контекста и может здорово ускорить всё дело. В коде приложения (например, в обработчике кнопки) обычно не нужно.
• Исключения не теряются! Если в асинхронной операции (в том же GetStringAsync) вылетело исключение, оно не сгинет. Оно прилетит прямо тебе в лицо, но в момент, когда ты сделаешь await на этой задаче. Так что оборачивай в try-catch именно await, а не просто вызов метода.

Вот и вся наука. Асинхронность — не чтобы быстрее стало, а чтобы не тормозить. Чтобы поток не простаивал, пока где-то там идёт ввод-вывод (сеть, диск, база данных). Освободили его — пусть других дел делает.