Inline-режим: бот в поле поиска

Бот-словарь терминалов Go живёт в чате, и чтобы посмотреть значение слова, пользователь должен открыть диалог, написать команду, прочитать ответ — четыре шага ради справки. Inline-режим сжимает их до двух: в любом чате, даже в группе с друзьями, человек набирает @имябота и первые буквы термина, а над полем ввода появляются карточки-подсказки; нажатие вставляет готовый текст в сообщение. Это тот же механизм, которым пользуются @gif и @pic при поиске картинок, и он меняет роль бота: из собеседника он становится службой подсказок, доступной из поля ввода каждого чата. Механика на Go держится на двух объектах: входящий InlineQuery и ответ AnswerInlineQuery со списком результатов. Ниже — включение режима, ветка в цикле обновлений, статьи с кэшированием и честный разбор того, почему бот с работающим кодом может молчать.

Пользователь начал набирать @имябота — Telegram присылает в цикл обновлений объект InlineQuery, у которого Message равен nil: это не сообщение в чат, а запрос подсказок. Рабочие поля четыре. ID — идентификатор запроса, на него надо ответить. From — кто ищет: для персонализации и лимитов. Query — сам поисковый запрос, обрезанный по текущей позиции курсора. Offset — строка пагинации для длинных списков. Первым делом режим надо включить: в BotFather команда /setinline, выбор бота и подсказка-плейсхолдер для поля ввода — без этого апдейты InlineQuery не приходят вовсе, и код будет безошибочно молчать. Ответ обязателен на каждый запрос, включая пустой Query: пользователь стёр буквы — бот должен вернуть пустой список, иначе клиент держит старые подсказки. Ветка в цикле ставится рядом с проверкой CallbackQuery из девятого урока: update.InlineQuery != nil — своя ветка со своим обработчиком.

Ответ строится из списка результатов, а простейший результат — статья: NewInlineQueryResultArticle(id, title, text) создаёт карточку с заголовком и текстом, который вставится в поле ввода при выборе. Первый аргумент — короткий идентификатор результата: он нужен, чтобы потом узнать выбранный вариант в ChosenInlineResult, и обычно собирается как индекс или ключ записи. Одним ответом уходит до пятидесяти результатов — для подсказок хватает трёх-пяти, длинные списки режутся по Offset. Отправляет ответ bot.AnswerInlineQuery с InlineQueryConfig, где InlineQueryID равен iq.ID, а Results — срез интерфейсов. Тонкость: Results имеет тип []interface{}, и каждый результат придётся приводить к этому типу при добавлении — особенность сигнатуры библиотеки v5. Ответ должен уйти быстро: клиент показывает подсказки только живому ответу, а Telegram хранит результаты в кэше и не ждёт вечности.

У InlineQueryConfig есть поля, которые управляют тем, как Telegram кэширует и переиспользует ответы. CacheTime — срок жизни ответа в секундах: по умолчанию Telegram держит результаты запроса пять минут и не дёргает бота повторно на тот же запрос от того же пользователя. Для словаря терминов это подарок: статичные подсказки отдаются мгновенно, нагрузка на бота падает в разы. Для живых данных — курса валют, остатков на складе, свободных слотов — кэш вредит, и CacheTime ставят в единицу или ноль. IsPersonal делает результаты приватными: без него один ответ может быть показан участникам чата, где искали — неважно для терминов, критично для личных документов и цен. Offset и его разбор вместе с ChosenInlineResult закрывают продвинутые сценарии: пагинация и статистика выбора — но и без них бот-словарь уже полноценный.

Свяжем механику с реальным сценарием. Словарь — срез структур Term с полями Name и Meaning, штук сорок-пятьдесят для учебного проекта. Обработчик фильтрует его по iq.Query: strings.Contains(strings.ToLower(t.Name), strings.ToLower(iq.Query)) — регистр приводится с двух сторон, иначе «КАРТА» не найдёт карту. На первые три совпадения создаются статьи: идентификатор — индекс в словаре, заголовок — термин, вставляемый текст — значение. Кэш CacheTime 300 не мешает: словарь меняется с релизами, а не с секундами. Логика поиска — чистый Go над строками и срезами, и она полноценно тестируется без Telegram: unit-тесты на фильтр ловят и регистр, и пустой запрос, ещё до первого запуска бота. Когда словарь вырастет за сотню записей, фильтр по памяти переедет в Redis с поиском по множествам — механика inline при этом не изменится.

Статья из конструктора вставляет плоский текст, а для подсказок с разметкой есть второй конструктор — NewInlineQueryResultArticleHTML: вставляемый текст разбирается как HTML, и в чат уходит сообщение с жирным, курсивом и кодом из тринадцатого урока. Пример словаря выигрывает сразу: значение термина с кодом в теге code выглядит в чате как настоящий фрагмент документации, а не как строка с квадратными скобками. У каждого результата есть ещё два полезных поля: Description — серая строка под заголовком, куда уходит усечённое значение термина, и ThumbnailURL — миниатюра слева от карточки. Один нюанс безопасности наследуется из урока про форматирование: в разметку результата попадает пользовательский запрос? экранируйте его тем же html.EscapeString, иначе скобка из поиска сломает вставку у получателя сообщения.

Клиент шлёт InlineQuery на каждое изменение поля: пользователь набрал слово из восьми букв — бот получил восемь запросов, включая одиночную m. Учебный фильтр по сорока терминам это переживёт усмехаясь, но словарь на тысячи записей с запросом в базу на каждую букву положит и Redis, и лимиты API. Лечение многослойное. Сначала честный порог: запросы короче двух букв отвечают пустым списком — клиент всё равно показывает мусор, который хуже отсутствия подсказок. Второй слой — CacheTime: уже включённое кэширование съедает повторные запросы той же строки. Третий — счётчик: тяжёлый поиск оборачивается таймером, который не даёт чаще одного запроса в секунду на пользователя, механика та же, что в rate limiter. Для учебного словаря хватает первых двух слоёв, но привычка считать запросы на каждую букву экономит потом ночные инциденты с настоящей базой.

AnswerInlineQuery отдаёт подсказки, но не говорит, чем всё кончилось: выбрал ли человек вариант или стёр запрос. Обратная связь приходит отдельным апдейтом — ChosenInlineResult с полями From, ResultID и Query. Для его получения в BotFather включается /setinlinefeedback, и в цикле появляется третья ветка спец-апдейтов. Зачем это боту-словарю: статистика — какие термины ищут, какие подсказки реально вставляют; на этих числах живут и сортировка результатов, и решение о новых статьях словаря. Формат простой: по ResultID — а мы клали туда term-с-индексом — наращиваем счётчик в Redis, и через неделю видно топ терминов. Без включённого фидбека бот тоже работает, просто вслепую: подсказки уходят в никуда, и качество поиска растёт только усилиями автора. Это тот же принцип, что и AnswerCallbackQuery из девятого урока: телеметрия нажатий — половина ценности интерактивных режимов.