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

Короткий ответ: да, можно, но с пониманием последствий

В Go оставлять канал открытым — абсолютно нормальная практика, если вы понимаете, что делаете. Главное правило: канал не обязан быть закрыт, если его больше никто не использует. Сборщик мусора (GC) в Go умный: когда на канал больше нет ссылок и он недоступен, GC его очистит. Утечки памяти из-за открытых каналов случаются редко, но есть нюансы.

Когда канал нужно закрывать?

Закрытие канала — это сигнал для получателей, что данных больше не будет. Вот типичные случаи:

• Итерация по каналу с range: если вы используете for v := range ch, то канал должен быть закрыт, иначе цикл будет ждать вечно.
• Несколько получателей: если несколько горутин читают из одного канала, закрытие — единственный способ сообщить им "стоп".
• Паттерн Fan-out/Fan-in: когда вы распределяете работу между воркерами, закрытие канала задач сигнализирует, что новых задач не будет.

Когда можно не закрывать?

• Одноразовая коммуникация: как в вашем примере — одна горутина отправляет одно значение, и программа завершается. Закрытие избыточно.
• Канал используется только для синхронизации: например, как chan struct{} для сигнала "готово".
• Канал живёт внутри горутины и умирает вместе с ней: если канал создан и используется только внутри одной горутины, а потом горутина завершается — GC сделает свою работу.

Пример: когда закрытие обязательно

package main

import (
	"fmt"
	"time"
)

func producer(ch chan int) {
	for i := 0; i < 5; i++ {
		ch <- i
		time.Sleep(100 * time.Millisecond)
	}
	close(ch) // Без этого main зависнет на range
}

func main() {
	ch := make(chan int)
	go producer(ch)

	for v := range ch { // Ждёт close(ch)
		fmt.Println(v)
	}
	fmt.Println("Все данные получены")
}

Пример: когда закрытие не нужно

package main

import (
	"fmt"
	"time"
)

func worker(id int, jobs <-chan int, results chan<- int) {
	for j := range jobs {
		results <- j * 2
	}
}

func main() {
	jobs := make(chan int, 5)
	results := make(chan int, 5)

	// Запускаем 3 воркера
	for w := 1; w <= 3; w++ {
		go worker(w, jobs, results)
	}

	// Отправляем задачи
	for j := 1; j <= 5; j++ {
		jobs <- j
	}
	close(jobs) // Закрываем канал задач — воркеры завершатся

	// Собираем результаты — канал results можно не закрывать,
	// так как мы точно знаем, сколько результатов ожидать
	for r := 1; r <= 5; r++ {
		fmt.Println(<-results)
	}
	// results остаётся открытым, но это нормально
}

Основные правила

1. Закрытие — ответственность отправителя. Никогда не закрывайте канал со стороны получателя — это вызовет панику.
2. Не закрывайте канал, если есть риск повторного закрытия. Используйте sync.Once или defer с проверкой.
3. Закрытие не является обязательным для освобождения ресурсов. GC справится сам, если канал больше не используется.
4. Помните о горутинах: если горутина висит на чтении из открытого канала, который никогда не закроют и не отправят данные — это утечка горутины (более опасная, чем утечка канала).

В вашем примере канал done можно смело оставлять открытым. Программа завершится, все ресурсы будут освобождены. Главное — не путайте закрытие канала с освобождением памяти: это разные вещи.

// Только для отправки
func sender(ch chan<- int) {
    ch <- 42
    close(ch) // Ок, мы отправители
}

// Только для чтения
func receiver(ch <-chan int) {
    for v := range ch {
        fmt.Println(v)
    }
    // close(ch) // Ошибка компиляции!
}

package main

import (
    "context"
    "fmt"
    "time"
)

func worker(ctx context.Context) {
    select {
    case <-time.After(2 * time.Second):
        fmt.Println("Работа завершена")
    case <-ctx.Done():
        fmt.Println("Отменено:", ctx.Err())
    }
}

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    go worker(ctx)
    time.Sleep(1 * time.Second)
    cancel() // Сигнал остановки
    time.Sleep(1 * time.Second)
}