Установка и первый запуск Chrome

Проект собирается как обычный Go-модуль: папка, go mod init, добавление пакета. Никаких шагов вне Go-экосистемы не существует — это главная разница с браузерными инструментами из других языков, где к проекту прилагается бинарник драйвера, который должен совпадать по версии с браузером. В chromedp chromedriver не нужен в принципе: библиотека общается с Chrome по протоколу отладки, встроенному в сам браузер, а сам chromedp — чистый Go без cgo, поэтому кросс-компиляция не страдает. chromedp установка сводится к трём командам терминала, а версии пакета и его зависимостей фиксируются в go.mod и go.sum штатным механизмом модулей. Требования к окружению минимальные: установленный Chrome или Chromium — тот же, что стоит у вас на рабочей машине, и достаточно свежий Go. Для серверов есть путь аккуратнее: Docker-образ с предустановленным браузером, чтобы версии не гуляли между машинами, — ему посвящён отдельный урок про Docker и серверное окружение, а пока работаем локально.

Сердце программы — две функции, и важно понимать разницу между ними. chromedp.NewContext(context.Background()) только готовит контекст: он запоминает настройки сессии, но не запускает ни одного процесса. Проверить это легко — поставьте после NewContext вызов os.Exit и убедитесь, что в системе не появилось ни одного процесса браузера. Ленивость здесь осмысленная: пока нет действий, браузер не нужен. Процесс стартует на первом chromedp.Run — это самый дорогой вызов программы, на него уходят и старт браузера, и подключение к нему. Отсюда практическое правило: NewContext и Run разделяют Initialization и работу, а между ними удобно навешивать таймауты. Вторая функция — cancel из пары: отмена первого контекста закрывает весь браузер, поэтому defer cancel() в main — обязательная гигиена каждого примера курса. Забытый cancel не приведёт к ошибке компиляции, но оставит висеть процесс Chrome — на ноутбуке это заметно по вентилятору, а на сервере — по памяти, которая кончилась в три часа ночи. Ещё одна деталь того же семейства: контекст можно готовить заранее, и это дёшево — программа создаёт сессии про запас и запускает их по мере необходимости, потому что цена NewContext — записать настройки, а не запустить процесс. Ленивость тут не экономия ради экономии: старт браузера — самое хрупкое место программы, и группировать его в одном месте — значит видеть все точки, где он может не удастся.

При старте библиотека ищет браузер по списку стандартных мест, и список этот зависит от операционной системы. На macOS проверяются приложения Chromium и Google Chrome в папке Applications. На Windows — путь через PATH и папки Program Files, включая профиль пользователя в AppData. На Linux список длиннее всего: chromium, chromium-browser, google-chrome, google-chrome-stable и его бета-варианты, /usr/bin/google-chrome, /usr/local/bin/chrome, а также /snap/bin/chromium — на Ubuntu браузер часто живёт именно в snap. Первый найденный бинарник и станет рабочим. Отсюда частая путаница на Linux: у вас стоит chromium, программа ищет google-chrome — и находит, потому что поиск идёт по всему списку, а не по одному имени. Если браузер лежит в нестандартном месте — кастомная сборка, отдельная версия для тестов, — путь передают явно опцией ExecPath при создании allocator-контекста, о котором ниже. Когда поиск ни к чему не привёл, chromedp не молчит: он возвращает ошибку запуска с именем, которое не нашлось, — и это обычно первый сигнал проверить, установлен ли браузер вообще. Список путей не секретная величина, а задокументированное поведение: на него можно опираться в скриптах развёртывания, зная, где именно следует ожидать бинарник.

chromedp стартует Chrome с набором флагов по умолчанию, и главный среди них — headless: окно не рисуется, интерфейс не существует, но движок полностью рабочий. К этому режиму добавлены тишина звука и скрытые полосы прокрутки — детали, которые не мешают автоматизации. Для повседневных задач headless — правильный режим: быстрее старт, меньше памяти, работает на сервере без дисплея. Но при отладке он прячет самое ценное — собственно страницу. Половина вопросов новичков — «почему селектор не находится» — решается за минуту, когда запускаешь программу с видимым окном и смотришь, что реально открылось: редирект на капчу, баннер согласия с куками, мобильная версия. Включается окно одной опцией Flag(«headless», false) из блока выше — базовый набор флагов при этом сохраняется. Отдельный практический нюанс: даже в headless у страницы есть размеры окна, и от них зависит вёрстка, которая отрисуется. Размер задают опцией WindowSize — это заметно на сайтах с адаптивом, где от ширины вьюпорта меняется вся сетка. Последний штрих к режимам: окно — не только отладка, но и редкие задачи со свойствами, привязанными к отображению, вроде печати страницы в PDF с точными полями; но в повседневной работе headless возвращается сразу, как только причина отладки устранена.

Первый Run — самое насыщенное место всей программы, и полезно знать его этапы. Сначала chromedp собирает аргументы командной строки из опций allocator: headless, отключённые первые-запуски, порт отладки со случайным номером — если порт не задан явно, — и готовит временный каталог профиля: по умолчанию свежая папка в системном tmp, чтобы сессии не мешали друг другу и не тащили историю; каталог сразу уезжает в браузер опцией user-data-dir. Затем стартует процесс Chrome с пустой первой страницей, и библиотека читает его вывод, пока там не появится строка с адресом отладки — на неё вешается WebSocket-подключение; если браузер молчит слишком долго, Run завершается ошибкой таймаута чтения адреса. После подключения создаётся вкладка — target, — и только теперь исполняются ваши действия. Всё это занимает доли секунды на быстрой машине, но на слабом CI растягивается заметно, поэтому первый Run и любят оборачивать запасным таймаутом. Здесь же живут две типовые ошибки. Первая — запуск как root в Linux-контейнере без песочницы Chrome: chromedp сам добавит нужный флаг, но понимать механику стоит. Вторая — context canceled посреди работы: соединение с браузером оборвалось, процесс убит или закрыт вручную, и chromedp отменил контекст, чтобы не врать про успех. Правильная реакция на неё — не глушить, а логировать и решать: ретрай с новым контекстом или сигнал о проблеме окружения. Знание этих этапов экономит часы: когда программа зависает, по месту затыка сразу видно, что сломалось — старт процесса, подключение или уже сами действия.