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

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

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

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

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

Однонаправленные типы каналов позволяют выразить эту границу в сигнатуре функции. Подход уменьшает связанность компонентов и переносит часть проверок с этапа выполнения на этап компиляции.

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

Если функция принимает двунаправленный канал, компилятор разрешает ей и отправлять значения, и получать их, и закрывать канал. Это расширяет полномочия функции даже тогда, когда по смыслу она должна только производить данные или только читать их.

Лишнее право на операцию может привести к ошибке: например, функция-потребитель случайно отправит значение, а функция-производитель начнёт читать канал и изменит протокол взаимодействия. Ошибки закрытия особенно опасны, поскольку отправка в закрытый канал вызывает панику.

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

Для отправки используется тип chan<- T, для получения — <-chan T, где T — тип элемента. Двунаправленный тип chan T можно неявно передать туда, где ожидается любой из этих однонаправленных типов.

package main

func produce(out chan<- int) {
	defer close(out)
	out <- 42
}

func consume(in <-chan int) int {
	return <-in
}

func main() {
	ch := make(chan int)
	go produce(ch)
	_ = consume(ch)
}

В примере produce не может читать из out, а consume не может отправлять в in. Ограничение проверяется компилятором; во время выполнения обе функции работают с тем же объектом канала, включая его буферизацию и правила блокировки.

Направление не определяет владение каналом автоматически. Обычно отправитель отвечает за завершение потока значений и может закрыть канал, если именно он знает, что новых значений больше не будет. Получатель обычно читает канал до закрытия, но тип <-chan T не позволяет ему вызвать close.

Канал только для отправки типа chan<- T закрывать можно. Это важно: направление запрещает получение, но не запрещает закрытие. Поэтому одного ограничения направления недостаточно для полного контроля жизненного цикла — ответственность за закрытие должна быть частью договорённости между компонентами.

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

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

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

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

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

Выбранный вариант — возвращать из функции-производителя <-chan T, а принимать канал для публикации как chan<- T. В результате вызывающий код видит только чтение результатов, производитель — только отправку, а попытки нарушить роли обнаруживаются компилятором. Это не устраняет ошибки отмены или блокировок, но заметно сужает пространство возможных ошибок и упрощает ревью.

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

1. Можно ли передать канал только для получения обратно функции, которая ожидает двунаправленный канал?

Нет. Направление можно сузить: chan T передаётся как chan<- T или <-chan T. Обратно восстановить запрещённые возможности нельзя ни неявным присваиванием, ни обычным приведением типа, потому что это разрушило бы гарантию ограничения API.

2. Может ли функция, принимающая канал только для отправки, закрыть его?

Да. Операция close разрешена для двунаправленного и канала только для отправки, но запрещена для канала только для получения. Поэтому chan<- T ограничивает направление передачи данных, но не является доказательством того, что функция должна или безопасно может закрыть канал.

3. Защищают ли однонаправленные типы от гонок данных?

Нет. Они ограничивают набор допустимых операций над каналом, но не защищают обычные переменные, к которым обращаются разные горутины. Для публикации состояния нужно использовать синхронизацию, такую как передача через канал, sync.Mutex или атомарные операции; само наличие типа <-chan T или chan<- T не делает произвольную память безопасной.