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

После закрытия буферизованного канала получатель сначала получит все значения, которые уже находятся в буфере. Когда буфер опустеет, операция получения немедленно вернёт нулевое значение типа канала и признак ok == false.

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

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

Такой подход особенно удобен для потоков данных: производитель отправляет значения, закрывает канал после окончания работы, а потребитель обрабатывает уже накопленные данные и корректно завершает цикл.

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

Неверно считать, что закрытие немедленно удаляет буфер или что после него получатель продолжит блокироваться. Буфер сохраняется, поэтому уже отправленные значения нельзя потерять только из-за закрытия канала.

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

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

У получения из канала есть две формы: значение можно получить отдельно или вместе с признаком успешности. Вторая форма позволяет различить настоящее нулевое значение и состояние «канал закрыт и пуст».

package main

import "fmt"

func main() {
	ch := make(chan int, 2)
	ch <- 7
	ch <- 9
	close(ch)

	for {
		value, ok := <-ch
		fmt.Println(value, ok)
		if !ok {
			break
		}
	}
}

Результат будет логически таким: 7 true, 9 true, затем 0 false. Нулевое значение 0 в последней строке не является отправленным сообщением.

Цикл for range также корректно обрабатывает этот случай: он получает все буферизованные значения и завершается после закрытия и опустошения канала. При этом закрывать канал должен владелец отправки, когда он гарантированно больше не будет отправлять.

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

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

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

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

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

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

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

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

Да, но только по второму результату операции получения. Для отправленного нулевого значения ok будет true, а для закрытого и пустого канала — false. Поэтому проверка только самого значения некорректна, если нулевое значение допустимо как данные.
Завершится ли цикл range сразу после закрытия буферизованного канала?

Нет. Он продолжит получать значения из буфера и завершится только после того, как буфер будет исчерпан. Закрытие означает запрет новых отправок, но не отменяет уже выполненные отправки.
Что произойдёт, если одна горутина читает канал, а другая закрывает его, пока отправитель ещё работает?

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