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

В select операция с nil-каналом никогда не становится готовой, поэтому соответствующая ветвь фактически отключается. Достаточно присвоить каналу значение nil, а для повторного включения вернуть в переменную рабочий канал.

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

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

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

В цикле обработки событий набор каналов может меняться: например, канал отправки следует отключить, пока очередь пуста, или канал получения — пока обработчик занят. Если оставить такую ветвь активной, select продолжит учитывать её и код будет сложнее контролировать.

Неверная замена nil-канала закрытым каналом опасна: получение из закрытого канала считается готовым, а отправка в него приводит к панике. Поэтому для временного отключения ветви нужен именно nil-канал, а не закрытие канала.

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

Операция отправки в nil-канал и операция получения из него блокируются навсегда. Поскольку select выбирает только готовые операции, case с nil-каналом он игнорирует как постоянно заблокированный.

package main

func main() {
    var out chan int
    in := make(chan int)

    select {
    case out <- 1:
        panic("ветвь отключена")
    case <-in:
        panic("данных пока нет")
    default:
        // Выполняется, потому что обе операции не готовы.
    }
}

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

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

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

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

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

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

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

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

Немедленно выполнится default, потому что ни одна операция с nil-каналом не готова. Поэтому такой select не блокируется и может превратиться в busy loop, если находится внутри цикла без паузы или другой работы.
Что произойдёт, если все ветви select используют nil-каналы и default отсутствует?

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

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