Состояние диалога: анкета по шагам

Всё, что бот умел до сих пор, работало без памяти: каждое сообщение обрабатывалось само по себе. Но стоит попросить пользователя заполнить анкету — имя, потом возраст, потом город, — и этого мало: бот обязан помнить, что уже спросил и что дождался. Это и есть состояние диалога, а в чистом виде — конечный автомат, FSM: ограниченный набор состояний и правила переходов между ними. Для телеграм бота на Go словарь «пользователь → шаг» естественно живёт в map[int64]string: ключ — chat_id, значение — имя текущего состояния. Вокруг карты вырастает вся дисциплина урока: кто и когда пишет в неё, как сбрасывать зависшего пользователя и что произойдёт при перезапуске процесса. К концу урока бот проведёт анкету по шагам, не спутается, если посреди неё написать /help, и честно потеряет все данные при рестарте — так мы увидим, зачем существует следующий урок про хранение данных.

Конечный автомат из учебника выглядит пугающе, но для бота это три вещи. Набор состояний — строковые константы: stepName, stepAge, stepCity. Начальное условие — отсутствие записи в карте: пустая строка, которую Go возвращает при чтении несуществующего ключа, означает «пользователь свободен, анкеты нет». Переходы — присваивания: после ответа на имя кладём в карту шаг возраста. Никаких библиотек для первого FSM не нужно: карта, константы, switch — весь каркас. Состояния называйте с префиксом сценария: анкета:имя, опрос:вопрос2 — по логу сразу видно, в каком сценарии живёт пользователь. Главное правило автомата: в каждый момент у пользователя ровно одно состояние, и все ветвления в обработчике идут по нему, а не по эвристикам вида «а что он писал раньше». Как только в коде появляется второе место, где решается, на каком шаге пользователь, автомат сломан — состояние должно читаться из карты, а не угадываться.

Ключом карты в уроке выбран chat_id, и в личных чатах это совпадает с From.ID — числа одинаковые. Разница проявляется в группах: у чата Chat.ID свой, отрицательный, а From.ID — личный номер автора сообщения. Анкета с ключом chat_id в группе станет общей на всех: один человек назовёт имя, второй попадёт на шаг возраста с чужим вопросом. Правило выбора: сценарий на диалог — ключ chat_id, сценарий на человека — From.ID. Опрос участников, личные настройки, чья-то анкета — всегда From.ID. Счётчик сообщений в группе, режим молчания чата, общая заметка — chat_id. Для уверенности храните оба: структура UserState с полями ChatID и UserID живёт дольше учебного проекта и не требует миграций, когда сценарии разделятся.

Сейчас цикл обновлений один: GetUpdatesChan отдаёт апдейты последовательно, и гонок на карте нет. Но состояние будут трогать не только сообщения. В девятнадцатом уроке появится горутина с тикером, которая шлёт напоминания и тоже захочет читать карту; в уроке про рассылки — фоновая отправка. Параллельная запись в map в Go не «грязная», а смертельная: runtime убивает процесс с fatal error: concurrent map writes, и поймать это нельзя — только не допускать. sync.Mutex вокруг каждой операции с картой стоит наносекунды и делает состояние безопасным заранее. Мьютексы разобраны в отдельном уроке продвинутого курса — там же про race detector, который ловит такие баги под нагрузкой. Спорное мнение напоследок: sync.Map для этого случая не нужен — он рассчитан на кэши с редкой записью, а у бота запись на каждое сообщение. Обычный mutex с defer Unlock честнее и проще в отладке.

Состояние без пути назад — тюрьма для пользователя. Сброс делается delete(b.states, chatID): запись исчезает, следующее чтение вернёт пустую строку, автомат считает человека свободным. Важно, что delete безопасен и для отсутствующего ключа — паники нет, проверять «а был ли он» не нужно. Правило порядка: сначала команды, потом состояния. /start и /cancel сбрасывают анкету целиком, /help отвечает справкой независимо от шага. Отдельная проблема, о которой молчат туториалы, — время. Карта не умеет стареть: пользователь бросил анкету на шаге возраста и ушёл на неделю — запись висит, и когда он вернётся, бот всё ещё требует возраст. Для учебного бота это приемлемо; в продакшене к состоянию добавляют время последней активности и чистят устаревшее — механика появится вместе с Redis в следующем уроке. Второй честный вариант — вообще не хранить состояние в памяти, а восстанавливать его из базы по факту.

Анкета из урока на шаге возраста примет что угодно: «двадцать», «qwerty», случайный стикер превратится в пустую строку — и все эти ответы уедут дальше как возраст. Диагноз универсальный: переход выполнен, валидации не было. Лечение по схеме: на каждом шаге сначала проверяем формат, при неудаче остаёмся в том же состоянии и объясняем, что нужно; переход — только за корректный ответ. Возраст — strconv.Atoi плюс границы, город — непустая строка после TrimSpace, время — разбор по шаблону. Вторая половина ошибки — данные: три анкеты из ста с «qwerty» в поле возраста испортят любую статистику, а чистить продакшен-таблицу никто не любит. Проверка на входе стоит одну функцию и работает годами — редкое вложение с такой доходностью.

Карта состояний живёт в памяти процесса, и это компромисс с известной ценой. Перезапуск бота — деплой, падение, обновление на VPS — стирает всех, кто стоял посреди анкеты: пользователи получат не диалог, а молчание и заново начатую анкету. Для учебного проекта это честная цена, для продакшена нет: состояние переезжает в Redis или базу, а карта с мьютексом остаётся учебным каркасом. Вторая цена — масштаб: один процесс бота держит одну карту, и горизонтальное масштабирование с ней не работает — ещё один аргумент за внешнее хранилище. Третья — данные: имя и возраст пользователя — персональные данные, и держать их в оперативке вечно плохая идея по определению. До всего этого мы дойдём в уроке про хранение данных, а итоговый проект курса соберёт бота-трекер привычек уже на постоянном хранилище. FSM при этом останется тем же: поменяется только backend у пары методов.

На каждую технологию найдётся фреймворк конечных автоматов, и для Go-ботов их предлагают регулярно. Я не пользуюсь ими до последнего: карта со строками и switch прозрачна, дебажится печатью состояния и не тянет зависимостей. Граница, где мнение сдаётся: десятки сценариев с ветвлениями внутри сценариев, когда переходы зависят и от шага, и от собранных данных, — там граф состояний хочется видеть декларацией, а не россыпью case. Созревание простое: пока код автомата помещается на один экран, библиотека — лишний слой. Как только экран кончился, сначала выносите сценарии в отдельные функции, и лишь потом смотрите в стороны фреймворков: чаще всего хватает именно функций.