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

Повторное закрытие уже закрытого канала вызывает панику. Закрытие канала не является идемпотентной операцией: оно переводит канал в закрытое состояние только один раз.

Отправка в закрытый канал также вызывает панику, тогда как чтение из закрытого канала допустимо и возвращает оставшиеся значения, а после их исчерпания — нулевое значение с признаком закрытия.

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

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

Чтобы такая модель оставалась однозначной, закрытие рассматривается как событие, выполняемое владельцем канала. Язык не делает повторное закрытие безопасным автоматически, поскольку это обычно указывает на ошибку координации между горутинами.

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

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

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

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

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

Минимальная демонстрация поведения:

package main

func main() {
    ch := make(chan int)
    close(ch)
    close(ch) // паника: close of closed channel
}

close изменяет состояние канала на «закрыт». После этого получатели могут извлечь уже буферизованные значения; когда буфер пуст, чтение завершается немедленно с нулевым значением и признаком закрытия. Новые отправки невозможны и приводят к панике.

Проверка закрытия через двухзначную форму чтения подходит для получателя, но не решает задачу безопасного закрытия: несколько отправителей всё равно могут одновременно завершать работу. Функция recover обычно не является правильным способом скрывать такую ошибку, поскольку она маскирует нарушение протокола владения каналом.

Для защиты именно от повторного вызова close можно применить sync.Once, но это не делает безопасными параллельные отправки во время закрытия. Сначала нужно гарантировать завершение отправителей, а затем выполнять единственное закрытие.

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

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

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

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

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

Можно ли закрывать канал со стороны получателя, если отправители ещё не завершились?

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

Нет, универсальной безопасной проверки такого вида нет. Даже если получить информацию о состоянии канала, между проверкой и close другая горутина может изменить это состояние, поэтому возникает гонка. Надёжность обеспечивается синхронизацией владения и жизненного цикла, а не предварительной проверкой.
Что произойдёт, если закрытие канала и отправка выполняются конкурентно?

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