Odpowiedź.

W Go konstrukcja pętli for może obejmować blok inicjalizacyjny (init), sprawdzenie warunku i wyrażenie postfiksowe. Historycznie taki mechanizm został stworzony dla wygody pisania kodu i przyzwyczajenia do języków podobnych do C. Jednak w Go zakres zmiennej pętli (i) ma swoją specyfikę, która mocno wpływa na zachowanie wewnątrz zagnieżdżonych funkcji, zamknięć (closures) i gorutyn.

Problem — uruchamiając gorutyny lub zamknięcia na każdej iteracji pętli, często występuje nieoczekiwane zachowanie: zmienna i nie jest kopiowana, a "przechwytywana" przez odniesienie, a więc zamknięcie odwołuje się do wspólnej zmiennej pętli, która po zakończeniu pętli przyjmuje ostatnią wartość. To prowadzi do tego, że wszystkie gorutyny/closure zwracają ten sam wynik, chociaż logika mogła zakładać coś innego.

Rozwiązanie — jeśli konieczne jest przekazywanie wartości zmiennej każdej iteracji, użyj jawnego kopiowania zmiennej (poprzez dodatkową zmienną) lub przekaż ją jako argument do zamknięcia.

Przykład kodu:

for i := 0; i < 3; i++ {
    go func(j int) {
        fmt.Println(j)
    }(i) // Poprawnie! Skopiowana wartość
}

for i := 0; i < 3; i++ {
    go func() {
        fmt.Println(i)
    }() // Błąd: wszystkie gorutyny wydrukują 3
}

Kluczowe cechy:

W pętli for zmienna pętli jest niejawnie zadeklarowana w zasięgu bloku for
Przechwycenie zmiennej pętli w zamknięciu/gorutynie prowadzi do "podzielenia" zmiennej pomiędzy wszystkie instancje closure
Można to obejść kopiując zmienną do nowej zmiennej w każdej iteracji

Pytania z pułapką.

Czy zakres zmiennej for zmienia się przy użyciu break lub continue?

Nie. Zakres zmiennej zadeklarowanej w for zawsze ogranicza się do bloku tej pętli. Break lub continue tylko przerywają bieżącą iterację, ale nie "przekazują" zmiennej na zewnątrz.

Czy można przechwycić zmienną zadeklarowaną w części init for w metodzie poza pętlą?

Nie. Zmienna jest widoczna tylko wewnątrz samego for i wszystkich zagnieżdżonych w nim bloków, ale nie na zewnątrz po zakończeniu pętli.

Co się stanie, jeśli przechwycenie zmiennej nastąpi w wyrażeniu defer wewnątrz for?

Ta sama sytuacja: funkcja defer "zobaczy" nie wartość w momencie tworzenia, ale bieżącą wartość zmiennej w momencie wykonywania defer (zwykle — ostatnią wartość pętli).

for i := 0; i < 3; i++ {
    defer fmt.Println(i) // wszystkie defer wydrukują 3
}

Typowe błędy i antywzorce

Przechwycenie zmiennej pętli bez skopiowania do nowej zmiennej
Przekazywanie zmiennej pętli do funkcji anonimowej bez jej jawnego przekazania (efekt późnego przypisania)
Użycie defer wewnątrz pętli bez uwzględnienia zasięgu zmiennych

Przykład z życia

Negatywny przypadek

W serwerze webowym Go programista uruchomił kilka gorutyn do obsługi różnych portów, używając indeksu portu jako zmiennej pętli i bezpośrednio przechwytując ją w wyrażeniu lambda. Wszystkie gorutyny odwoływały się do jednego portu — ostatniego w tablicy.

Zalety:

Prosta, "jawna" realizacja pętli

Wady:

Niekorektna logika działania
Długo analizowany błąd

Pozytywny przypadek

W zespole wprowadzono zasadę — zawsze kopiować wartość zmiennej pętli do nowej zmiennej, którą już przechwytuje closure/gorutyna.