Установка robfig/cron и первый планировщик

robfig cron ставится как любая Go-зависимость. В корне модуля выполняется go get github.com/robfig/cron/v3 — команда допишет версию в go.mod и скачает пакет; дальше в коде импортируется путь github.com/robfig/cron/v3, а сам пакет называется просто cron. Обратите внимание на суффикс /v3: в Go мажорная версия второй и старше обязана жить в конце пути импорта, поэтому перепутать версии сложно — v3 не может подменить собой v2. Это же суёт под нос главное отличие тройки: старые статьи про gopkg.in/robfig/cron.v1 и github.com/robfig/cron/v2 описывают другой API, где AddFunc возвращал только ошибку, а часовых поясов и обёрток ещё не было. Если код из чужого блога не компилируется с «cannot use ... as EntryID» — почти всегда виновата смешанная версия. Установка cron для golang-проекта этим и ограничивается: никакой отдельной службы, демона или драйвера не нужно, зависимость чисто компиляционная и работает на любой платформе, где собирается Go.

cron.New() возвращает указатель на планировщик с настройками по умолчанию: пять полей в выражениях, локальный часовой пояс, без обёрток задач. Метод AddFunc принимает два аргумента — строку выражения и функцию без параметров и без возвращаемого значения — и возвращает пару значений: EntryID и error. Сигнатура func(spec string, cmd func()) (EntryID, error) — маркер третьей версии: парсер проверяет выражение немедленно, и опечатка вроде «0 25 *» вернёт ошибку прямо при старте, а не в три часа ночи молчанием. EntryID — целочисленный идентификатор зарегистрированной задачи; на этом уроке он просто печатается, но дальше станет инструментом: по нему снимают задачи с расписания и находят их среди прочих. Start() запускает внутренний цикл в отдельной горутине и возвращается мгновенно — это второй маркер v3, знакомый по документации: планировщик не управляет временем жизни main, и об этом — следующий блок.

Порядок вызовов AddFunc и Start в robfig/cron свободный: можно зарегистрировать все задачи заранее и затем запустить, можно запустить планировщик и добавлять задачи по ходу работы — оба сценария поддержаны, и вторая половина курса пользуется этим активно, когда расписание приходит из базы или меняется через админку. Новая задача начинает жить по своему выражению сразу после регистрации: планировщик при следующем проходе вычислит для неё ближайший момент запуска. Внутри всё устроено честно: каждое выражение один раз разбирается парсером в структуру расписания, дальше остаётся только сверка времени, поэтому сотня задач на планировщике не создаёт никакой нагрузки. Ещё одна практическая деталь: AddFunc возвращает уникальный EntryID даже для одинаковых функций — одна и та же задача, добавленная дважды, выполнится дважды, и библиотека не станет вас предупреждать. Если подозреваете, что регистрация может выполниться повторно, проверяйте это в своём коде: планировщик доверчив, как словарь.

Полезно один раз заглянуть под капот, чтобы дальше не удивляться поведению. После Start планировщик вычисляет для каждой зарегистрированной задачи ближайший момент запуска — метод Schedule.Next от текущего времени — и заводит таймер на самый ранний из этих моментов. Когда таймер срабатывает, все задачи с этим моментом уходят в собственные горутины, для каждой из них вычисляется следующий момент, и таймер заводится заново. Отсюда два практических вывода. Первый — про точность: пять полей означают минутную сетку, и задача выполнится в пределах своей минуты; секундная точность включается отдельной опцией и заслуживает отдельного урока, потому что там свои ловушки. Второй — про сдвиги времени: перевод часов обрабатывается через тот же вызов Next, но пересчёт происходит в момент срабатывания таймера, поэтому экзотические сценарии со скачками системных часов стоит проверять отдельно. Для типовых сервисов, которые тикают по минутам и часам, поведение ровно то, что ожидается: таймер сработал — задачи ушли — таймер заведён снова.

После go get в go.mod появляется строка с версией вида v3.0.1 — библиотека развивается неспешно и стабильно, мажорная тройка вышла в 2019 году и с тех пор сохраняет обратную совместимость сигнатур. Источник правды — pkg.go.dev/github.com/robfig/cron/v3: там лежат описания методов, опций и обёрток, и это стоит держать открытой вкладкой на первые пару недель. Структура модуля после установки не меняется: планировщик — это зависимость, а не отдельный слой проекта, и никаких папок вроде cron/ в своём дереве заводить не нужно. Единственное, что стоит решить заранее, — где будут жить регистрации задач: одна функция setupCron, принимающая зависимости и возвращающая готовый планировщик, спасёт main.go от превращения в свалку, когда задач станет больше пяти. Об этом приёме подробнее в уроке про задачи-структуры, а пока важно другое: установка закончена, зависимость в go.mod, импорт компилируется — дальше начинается синтаксис выражений.