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

Отправка в nil-канал и получение из него блокируются навсегда. Это отличается от закрытого канала: получение из закрытого канала завершается немедленно, а отправка вызывает панику.

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

Каналы в Go предназначены для передачи данных и синхронизации между горутинами. Их нулевое значение — nil — не требует отдельной инициализации, но означает отсутствие рабочего канала.

Такое поведение позволяет временно отключать ветку обмена данными, особенно внутри select, без добавления отдельных флагов состояния.

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

Если горутина отправляет данные или ждёт получение через nil-канал вне другого управляющего механизма, она зависает. Это может привести к утечке горутин, невыполнению WaitGroup и зависанию теста или сервиса.

В select случай с nil-каналом считается отключённым. Поэтому ошибочное присваивание nil может незаметно убрать обработку события, тогда как попытка закрыть nil-канал завершится паникой.

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

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

В select ветка с nil-каналом никогда не выбирается. Это используется для динамического включения и отключения каналов:

package main

func main() {
    var input <-chan int
    output := make(chan int)
    value := 1

    select {
    case v := <-input:
        _ = v
    case output <- value:
    default:
    }
}

Здесь получение из input отключено, потому что input равен nil. Ветка отправки может быть выбрана, если у output есть готовый получатель; иначе выбирается default.

У закрытого канала семантика другая: получение возвращает нулевое значение типа и признак закрытия, а повторное закрытие или отправка в закрытый канал вызывают панику. len и cap nil-канала равны нулю, но это не делает операции обмена неблокирующими.

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

Сервис читает данные из необязательного источника и одновременно принимает сигнал остановки. Один из вариантов — постоянно проверять отдельный флаг состояния. Это усложняет синхронизацию и может привести к гонкам.

Другой вариант — присвоить входной канал nil, когда источник отключён, и использовать его как ветку select. Плюс этого подхода — отсутствие активного опроса и простое управление набором событий; минус — случайный nil может навсегда отключить обработчик и выглядеть как обычное отсутствие событий.

Практичное решение — управлять nil-значением централизованно, документировать его смысл и проверять обязательные каналы при запуске. Тогда nil-канал становится намеренным механизмом отключения, а не скрытой ошибкой конфигурации.

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

Чем nil-канал отличается от закрытого?

Nil-канал блокирует отправку и получение навсегда. Закрытый канал не принимает отправку, но получение из него завершается немедленно: после исчерпания буфера возвращается нулевое значение и false в многозначной форме получения.

Что произойдёт в select, если все его каналы равны nil?

Если у select нет готовой ветки default, он блокируется навсегда. Nil-ветки не участвуют в выборе. Если присутствует default, будет выбрана именно она, поскольку активных операций нет.

Безопасно ли закрывать nil-канал после проверки?

Нет. Операция close над nil-каналом всегда вызывает панику. Кроме того, отдельная проверка на nil не защищает от изменения состояния другой горутиной между проверкой и закрытием. Владельцу канала следует явно определить, кто его создаёт и кто имеет право закрывать.