Почему при парсинге комментариев YouTube теряются ответы: двухуровневая пагинация и проверка полноты

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

Проблема не новая. Baskaya отмечал расхождение между числом ответов и фактически возвращённым контентом в старом обсуждении на Stack Overflow. В старых ответах есть догадки времён интеграции с Google+, и сегодняшние проблемы они не объясняют. По-настоящему полезен поставленный там вопрос: что вы считаете — ветки, комментарии или подмножество ответов, приложенное к ответу API?

В этой статье это различие объясняется на основе официальной документации по состоянию на 2026-9-5, а также описаны способы проверки результатов загрузки. Речь идёт об официальных правилах YouTube API; это не отчёт о тестировании EveryInfra, и восстановление недоступного контента не гарантируется.

Почему ответы в commentThreads неполные

Согласно документации ресурса YouTube, commentThread содержит комментарий верхнего уровня и, возможно, прикреплённые к нему ответы. Комментарий верхнего уровня находится в snippet.topLevelComment, а список ответов — в replies.comments, причём последний может быть лишь подмножеством. snippet.totalReplyCount — это число ответов на данный комментарий верхнего уровня, и его нельзя напрямую сравнивать с длиной всего списка веток. API комментариев YouTube от EveryInfra возвращает reply_count для каждого комментария. После выгрузки сверьтесь с ним, чтобы понять, сколько ответов у вас на самом деле.

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

Ещё одно различие, которое легко упустить, — идентификаторы веток и идентификаторы комментариев верхнего уровня. Их нужно читать и сохранять по отдельности из соответствующих ресурсов; если в одном примере две строки совпали, это не значит, что программа может всегда считать их взаимозаменяемыми. Одинаковый вид в модели данных не означает одинакового назначения в определении API.

Ведите прогресс пагинации отдельно для комментариев верхнего уровня и для ответов

Официальный метод commentThreads.list позволяет читать ветки по videoId и получать следующую страницу по nextPageToken из ответа. Верхний предел maxResults — не более 100 записей на страницу; это не запрос, который сразу отдаёт все комментарии к видео, и не признак того, что в ветке может быть не больше 100 ответов.

Для конкретного комментария верхнего уровня следуйте правилам comments.list: передайте ID этого комментария в parentId и обрабатывайте nextPageToken его собственного запроса ответов. Токен пагинации здесь относится к запросу ответов: его нельзя подставить обратно в запрос веток видео, как нельзя и повторно использовать токен другого родительского комментария.

Реализацию можно разделить на два уровня задач: задачи по видео находят комментарии верхнего уровня, а задачи по родительским комментариям догружают остальные ответы. Для каждого родительского комментария отдельно хранят позицию продолжения и причину остановки. Так обсуждение с необычно большим числом ответов не заставит заново запускать уже завершённые ветки.

Вместе с прогрессом стоит сохранять и условия запроса: использовался ли searchTerms, какой способ сортировки был выбран и какое видео было целевым. Если поиск с самого начала был ограничен ключевыми словами, последующие заявления о полноте могут относиться только к этой области запроса; нельзя опускать условия фильтрации в файлах экспорта, чтобы представить данные как «все комментарии к этому видео».

Фиксируйте условия завершения в результатах, а не только в логах

Рекомендуем разделять содержимое комментариев и прогресс сбора. Содержимое дедуплицируется по платформе и ID комментария с сохранением видео, связи с родительским комментарием и времени наблюдения, а прогресс описывает, на каком этапе находится текущая задача. Это рекомендации по проектированию на стороне приложения: перечисленные ниже поля не являются исходными полями ответа YouTube или EveryInfra.

Минимальная запись о прогрессе должна отвечать на вопросы: дошёл ли список веток до последней страницы, у каких родительских комментариев ответы получены до конца, какие остановились из-за ошибок запросов или бюджета задачи и когда было последнее подтверждение. Одного success: true недостаточно, чтобы выразить ситуацию «верхний уровень завершён, но у одного родительского комментария остались две ещё не полученные страницы ответов».

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

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

Неустранимые расхождения в количестве комментариев

Сначала проверьте иерархию объектов, условия фильтрации и двухуровневую пагинацию, а затем типы ошибок. Официальная документация по списку веток различает случаи с commentsDisabled, недостаточными правами и отсутствующим видео. Ни один из этих случаев не следует подавать как «у видео сейчас нет комментариев». Пустой массив по итогам успешного запроса и пустой массив, возвращённый потому, что клиент проглотил исключение, свидетельствуют о разном.

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

Рекомендуем формулировать статус так, чтобы его можно было проверить, например: «список веток по этому запросу пройден до конца, но две задачи по получению ответов для родительских комментариев ещё не завершены». Это честнее, чем «полнота 98%», ведь для такой цифры нужен надёжный общий знаменатель, рассчитанный по тем же правилам. Если знаменателя нет, не выдумывайте процент, который лишь выглядит точным.

Общие проблемы с HTTP и параметрами разобраны в разделе документации «Обработка ошибок API». Повторные попытки помогают при части временных сбоев, но не расширяют права доступа и не превращают частичный объект ответов в полный набор данных.

Проверка парсера на четырёх небольших выборках

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

1. В ветке меньше ответов, чем заявлено: программа должна создать задачу по ответам, а не сразу объявлять сбор завершённым.
2. У списка ответов есть следующая страница: программа должна продолжить обработку этого родительского комментария, а не только листать список веток видео.
3. Одна и та же страница прочитана дважды: итоговое число уникальных комментариев не должно удвоиться, а связи «родитель — потомок» должны остаться согласованными.
4. Запрос по родительскому комментарию завершился ошибкой: остальные результаты можно сохранить, но в экспорте нужно указать, что данные частично неполны, и не перезаписывать прежние корректные результаты пустыми списками ответов.

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

Выше приведены рекомендуемые тесты, а не реальные эксперименты с видео, выполненные для этой статьи. Если у вас уже есть JSON, экспортированный через API, эти структуры и состояния можно проверить офлайн, прежде чем решать, нужно ли разрешение на повторную загрузку данных.

Как передать выборку комментариев с явными границами

«Сколько записей собрано» — лишь часть результата. Экспорт, пригодный для анализа, должен также описывать цели, фильтры, время сбора, связи «родитель — потомок», способ дедупликации и незавершённые элементы. Аналитические отчёты должны наследовать эти границы и не отбрасывать пробелы, известные на предыдущих шагах, только потому, что процесс перешёл к этапу сводки.

Выбирая готовые API данных, используйте метод проверки каталога из руководства «Знакомство с унифицированными API данных», чтобы по пунктам подтвердить, какие поля и возможности пагинации реально предоставляются. Не переносите официальные параметры из этой статьи на другой набор API и не считайте, что «поддержка комментариев» означает охват всех уровней и исторического содержимого.

Главное в сборе комментариев YouTube — не постоянно увеличивать лимит на страницу, а следить за тем, чтобы можно было объяснить, к какому комментарию относится каждый ответ, как продвигается каждая задача пагинации и почему она была остановлена. Только тогда результаты сбора могут служить основой для анализа, а не превращаться в файл, по которому невозможно понять, что было пропущено.