Коротко: сам по себе ваш фрагмент
ch := make(chan int); go func() { ch <- $1$ }(); <-ch; close(ch)
в большинстве реализаций безопасен — это нерегистровый (unbuffered) канал: отправка в горутине блокируется до приёма в основном потоке, приём снимает блокировку, горутина завершается, затем вы закрываете канал, когда дальнейших отправок нет.
Возможные ошибки и паники
- Отправка в уже закрытый канал: любое `ch <- x`, где канал уже закрыт, вызовет panic `send on closed channel`.
- Закрытие канала дважды: `close(ch)` при уже закрытом канале — panic `close of closed channel`.
- Закрытие `nil`-канала: `close(nil)` — panic.
- Гонки/несинхронизированные операции: если один поток закрывает канал одновременно с тем, как другой пытается отправить в него, получится panic; это — логическая гонка состояния канала.
- При buffered-канале или при другом порядке действий (например, если отправляющий не синхронизирован с получающим) поведение может отличаться и привести к панике.
Правильные практики для продакшена
- Правило владения: тот, кто отправляет значения в канал (producer), должен его закрывать; получатели (consumers) не должны закрывать канал, если не явны гарантии, что отправок больше не будет.
- Для сигнала «больше нет значений» используйте `close(ch)` и у получателей idiom:
v, ok := <-ch
if !ok { /* канал закрыт */ }
или цикл:
for v := range ch { /* ... */ }
- Если несколько производителей — никто не должен закрывать канал извне; вместо закрытия используйте отдельный канал-сигнал (`done`) или `sync.WaitGroup`, или согласованный владелец, который закрывает канал после завершения всех производителей (например, владелец собирает producers и закрывает канал после WaitGroup).
- При необходимости гарантировать единственное закрытие используйте `sync.Once`:
var once sync.Once
once.Do(func(){ close(ch) })
- Для широковещательной отмены предпочтительнее `context.Context` или отдельный закрываемый `done`-канал; при широковещании закрытие канала — корректный способ оповестить всех получателей, но его тоже закрывает только один ответственный.
- Тестируйте с `-race` (go test -race) для обнаружения гонок.
- Не закрывайте канал просто чтобы «освободить» ресурсы — в большинстве случаев закрывать не обязательно. Закрытие нужно только для обозначения конца потока значений.
Вывод: в вашем примере аварий не будет при условии, что больше никто не попытается отправить в `ch` и `ch` не nil. В общем коде держите правило «sender closes», синхронизируйте завершение и используйте `ok`/`range`, `WaitGroup`, `context` или `sync.Once` для безопасного закрытия.