Код, который вы привели:

func main() {
ch := make(chan int)
go func() {
for i := 0; i < 3; i++ {
ch <- i
}
close(ch)
}()

for i := range ch {
go func() {
ch <- i
}()
}

}

разберём по шагам, что в нём не так, почему возможна паника и как это исправить.

1) Почему возникает паника

В вашей программе есть одна горутина, которая отправляет 0,1,2 в chan и затем закрывает этот канал.В main вы range по тому же каналу и для каждого принятого значения запускаете горутину, которая снова пытается отправить это значение в тот же канал.close(ch) выполняется прежде или во время выполнения этих «обратных» отправок — попытка отправить в уже закрытый канал приводит к панике: "send on closed channel".Кроме того, если канал незакрыт, но main уже не читает из него (range завершился), send в незаполненный небуферизованный канал заблокируется навсегда — дедлок. В текущем примере close делает панику более вероятной.

2) Дополнительные проблемы

Захват переменной цикла: внутри go func() вы используете i без передачи её в аргументы — замыкание захватит одну и ту же переменную i, и все горутины могут увидеть изменённое значение. В Go переменная range/for переиспользуется.Закрывать канал должен тот, кто гарантированно больше не будет в него отправлять. Если несколько отправителей — нужно координировать закрытие (чаще закрывает один "координатор" после WaitGroup).Отлавливать паники (recover) вместо исправления дизайна — плохая практика.

3) Как правильно синхронизировать и избежать паники
Общие правила:

Не отправляйте в канал после его закрытия.Один канал — одна ответственность: используйте отдельные входной/выходной каналы, если нужно читать и отправлять результаты.Используйте sync.WaitGroup, чтобы дождаться завершения рабочих горутин перед закрытием канала результатов.Передавайте значения в замыкание как аргумент (v := i; go func(v int){...}(v)).

4) Примеры исправлений

Вариант A — отправлять результаты в отдельный канал results и закрывать его после WaitGroup:

package main

import (
"fmt"
"sync"
)

func main() {
ch := make(chan int)
go func() {
for i := 0; i < 3; i++ {
ch <- i
}
close(ch)
}()

var wg sync.WaitGroup
results := make(chan int)
for v := range ch {
v := v // важный приём: захват значений безопасно
wg.Add(1)
go func(val int) {
defer wg.Done()
// какая‑то обработка...
results <- val
}(v)
}
// закрываем results после того, как все горутины завершились
go func() {
wg.Wait()
close(results)
}()
for r := range results {
fmt.Println(r)
}

}

Вариант B — если вы действительно хотите переиспользовать тот же канал (не рекомендуется), то нужно:

Никогда не закрывать канал до завершения всех отправителей.Иметь один «координатор», который закроет канал после wg.Wait().

Пример (НЕ рекомендуется менять назначение канала во время range — здесь показан принцип):

package main

import (
"fmt"
"sync"
)

func main() {
ch := make(chan int)
var wg sync.WaitGroup

// заполняющая горутина
go func() {
for i := 0; i < 3; i++ {
ch <- i
}
// не закрыаем ch здесь — будем закрывать после всех отправок
}()
// читаем 3 значения и для каждого делаем обратную отправку
for i := 0; i < 3; i++ {
v := <-ch
wg.Add(1)
go func(val int) {
defer wg.Done()
// отправляем обратно в ch
ch <- val + 10
}(v)
}
// ждём всех отправок и только потом закрываем/читаем
go func() {
wg.Wait()
close(ch)
}()
for r := range ch {
fmt.Println(r)
}

}

5) Краткие рекомендации

Избегайте отправки в канал, который вы range-ите/закрываете в другом месте, если не контролируете время закрытия.Используйте отдельные каналы для input/output или используйте буферизацию/WaitGroup, чтобы избежать гонок и паникующих send on closed channel.Передавайте значения в замыкание через параметры, чтобы избежать проблемы с повторным захватом переменной цикла.Не используйте recover для «скрытия» паник из-за неправильной синхронизации — лучше исправить логику.

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