Краткий ответ

sync.WaitGroup предназначен для ожидания завершения известного набора горутин и не передаёт данные. Канал предназначен прежде всего для обмена значениями или сигналами; его можно использовать для ожидания, но тогда нужно явно организовать отправку, получение или закрытие канала.

Исторический контекст

В конкурентных программах нужно разделять две задачи: обмен данными между выполняющимися компонентами и координацию их жизненного цикла. Каналы в модели Go решают задачу взаимодействия через передачу значений, а WaitGroup предоставляет отдельный счётчик незавершённых операций.

Такое разделение уменьшает риск использовать канал только как замену счётчику, когда данные передавать не требуется. Выбор примитива делает намерение программы очевиднее: WaitGroup сообщает о завершении работ, канал — о событии или значении.

Постановка проблемы

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

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

Подробное решение

WaitGroup хранит счётчик незавершённых работ. Add(1) регистрирует работу, Done() уменьшает счётчик, а Wait() блокируется, пока он не станет равен нулю. Типичный безопасный порядок — сначала зарегистрировать работу, затем запустить горутину; внутри горутины вызвать Done() через defer.

package main

import "sync"

func main() {
    var wg sync.WaitGroup
    for i := 0; i < 3; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            // Работа
        }()
    }
    wg.Wait()
}

Канал имеет другую семантику. Отправка и получение могут синхронизировать горутины, а закрытие канала может уведомить ожидающих получателей, но канал дополнительно задаёт правила владения, ёмкость, порядок сообщений и обработку закрытия. Поэтому канал уместен, когда завершение является частью потока событий или вместе с ним нужно передать результат.

WaitGroup не сообщает, какая работа завершилась, не переносит результат, не отменяет горутины и не собирает ошибки. Для этих задач применяют каналы, context.Context или специализированные конструкции, например errgroup, если она разрешена архитектурой проекта. Нельзя вызывать Add конкурентно с Wait, когда счётчик может быть нулевым: новая работа может не попасть в ожидаемый набор.

Ситуация из практики

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

Можно использовать канал результатов, если вызывающему коду нужны сами ошибки или частичные результаты. Минус — необходимо определить размер буфера или обеспечить постоянное чтение, иначе завершившиеся горутины могут заблокироваться на отправке.

Выбранный вариант — WaitGroup для ожидания плюс защищённое хранилище или отдельный канал для результатов. Это разделяет ответственность: WaitGroup отвечает только за завершение, а канал или другой механизм — за передачу данных. В результате добавление новых проверок не меняет протокол завершения и не создаёт скрытой зависимости от числа сообщений.

Что кандидаты часто упускают

1. Можно ли заменить WaitGroup закрытием канала?

Только если закрытие выполняется единственным координатором после того, как завершились все отправители. Обычно это означает отдельную горутину, которая вызывает Wait, а затем закрывает канал. Сам по себе канал не знает, сколько горутин должно завершиться, поэтому без такого протокола замена некорректна.

2. Что произойдёт, если вызвать Done() больше раз, чем было вызвано Add()?

Счётчик станет отрицательным, и WaitGroup завершится паникой. То же относится к вызову Add с отрицательным значением, если итоговый счётчик становится меньше нуля. Практически это означает, что каждая зарегистрированная работа должна иметь ровно один путь к Done, обычно гарантируемый defer сразу после входа в горутину.

3. Передаёт ли WaitGroup результаты или гарантирует отсутствие гонок?

Нет. Он гарантирует только ожидание достижения счётчиком нуля и соответствующую синхронизацию завершения зарегистрированных работ. Общие данные всё равно нужно защищать мьютексом, передавать через канал или организовать так, чтобы доступ после Wait происходил безопасно; сам WaitGroup не превращает конкурентные записи в последовательные.