How to iterate over a map in Go

1for k, v := range mRecommended

One range statement gives you the key and the value of every entry, exactly once each. There is no iterator to create, nothing to close, and no index — the two loop variables are the key and a copy of the value. The only thing to be careful about is what you do with the results: an aggregate is order-independent, but printed output is not, so collect and sort before you print.

package main

import (
	"fmt"
	"slices"
)

func main() {
	ports := map[string]int{"https": 443, "ssh": 22, "http": 80, "dns": 53}

	// The canonical loop: one key and one value per entry.
	lines := make([]string, 0, len(ports))
	for name, port := range ports {
		lines = append(lines, fmt.Sprintf("%s -> %d", name, port))
	}

	// Ranging a map has NO defined order, so sort before you print.
	slices.Sort(lines)
	for _, line := range lines {
		fmt.Println(line)
	}

	// Order-independent work needs no sorting -- a sum is a sum.
	total := 0
	for _, port := range ports {
		total += port
	}
	fmt.Println("entries:", len(ports), "total:", total)
}

Prints dns -> 53, http -> 80, https -> 443, ssh -> 22, then entries: 4 total: 598 — and it prints that on every run only because of the slices.Sort. Two details worth knowing: value is a copy, so assigning to it changes nothing (write m[k] = v back if you meant to update the map), and a range over a nil map is legal and simply runs zero iterations, so you never need a nil check before the loop.

2Keys only, values only

Drop the second variable and range yields keys alone — for k := range m — which also skips copying each value, a real saving when the values are big structs. Blank the key with _ for the mirror image. Go 1.23 added maps.Keys and maps.Values, which return iterators rather than slices, so they pair with slices.Sorted or slices.Collect.

package main

import (
	"fmt"
	"maps"
	"slices"
)

func main() {
	stock := map[string]int{"apple": 12, "banana": 0, "cherry": 7}

	// Keys only: one variable in the range.
	names := make([]string, 0, len(stock))
	for name := range stock {
		names = append(names, name)
	}
	slices.Sort(names)
	fmt.Println(names)

	// Values only: blank out the key with _.
	units := 0
	for _, n := range stock {
		units += n
	}
	fmt.Println("units:", units, "kinds:", len(stock))

	// Go 1.23+: maps.Keys/maps.Values return iterators, not slices.
	fmt.Println(slices.Sorted(maps.Keys(stock)))
	fmt.Println(slices.Sorted(maps.Values(stock)))
}

Prints [apple banana cherry], units: 19 kinds: 3, then [apple banana cherry] and [0 7 12]. Note that len(m) already counts entries — never range a map just to count it. And maps.Keys(m) is not the old golang.org/x/exp/maps.Keys, which returned a []K; the standard library version returns an iter.Seq[K], so wrap it in slices.Collect if you want the unordered slice, or slices.Sorted if you want it sorted.

3Why the order is random on purpose

The Go spec says the iteration order over maps "is not specified", and since Go 1.0 the runtime has actively randomised it: each range picks a random starting bucket and a random offset inside it. Early Go programs were accidentally depending on the incidental order of a particular implementation, so the team made the disorder loud enough to catch in development instead of in production. This snippet ranges the same four-entry map a thousand times and reports what it saw.

package main

import (
	"fmt"
	"maps"
	"slices"
	"strings"
)

func main() {
	m := map[string]int{"alice": 1, "bob": 2, "carol": 3, "dana": 4}

	orders := map[string]bool{} // every distinct order we see
	firsts := map[string]bool{} // every key that ever came out first

	for i := 0; i < 1000; i++ {
		keys := make([]string, 0, len(m))
		for k := range m {
			keys = append(keys, k)
		}
		orders[strings.Join(keys, ",")] = true
		firsts[keys[0]] = true
	}

	fmt.Println("more than one order in 1000 loops:", len(orders) > 1)
	fmt.Println("every key came out first at least once:", len(firsts) == len(m))
	fmt.Println("first keys seen:", slices.Sorted(maps.Keys(firsts)))
}

Both questions answer true, and the third line is first keys seen: [alice bob carol dana] — every key led at least once in a thousand loops. The map was never modified between iterations; the order still moved. Note the shape of the assertions: the snippet prints booleans and a sorted list rather than the raw orders, because printing the orders themselves would produce different output every run. That is the discipline this whole page is about.

4Iterating in a deterministic order

You cannot sort a map — it has no order to change. What you sort is a slice of its keys, and then you range that slice and look each value up. On Go 1.23+ the whole collect-and-sort step is a single expression, slices.Sorted(maps.Keys(m)). Ordering by value is the same idiom with a comparison that dereferences the map, plus a tie-breaker so that equal values still come out in a fixed order.

package main

import (
	"cmp"
	"fmt"
	"maps"
	"slices"
)

func main() {
	votes := map[string]int{"go": 98, "rust": 124, "zig": 35}

	// Collect the keys, sort them, range the SLICE -- works on every Go version.
	keys := make([]string, 0, len(votes))
	for k := range votes {
		keys = append(keys, k)
	}
	slices.Sort(keys)
	for _, k := range keys {
		fmt.Println(k, votes[k])
	}

	// Go 1.23+: the same collect-and-sort as one expression.
	fmt.Println(slices.Sorted(maps.Keys(votes)))

	// By VALUE instead: sort the key slice by what each key points at,
	// highest first, with the key itself as the tie-breaker.
	slices.SortFunc(keys, func(a, b string) int {
		return cmp.Or(cmp.Compare(votes[b], votes[a]), cmp.Compare(a, b))
	})
	fmt.Println(keys)
}

Prints go 98, rust 124, zig 35, then [go rust zig], and finally [rust go zig] — the same three keys reordered by vote count. The cmp.Or tie-breaker is not decoration: without it, two keys with equal values would be ordered by an unstable sort over a slice that arrived in random order, and your output would flicker again. Pre-sizing with make([]string, 0, len(votes)) avoids regrowing the slice, and the sort is O(n log n) each time — cache the sorted key slice if you iterate the same unchanged map in a loop. More ways to order the key slice are in sort a slice.

5Which form should you use?

6Deleting and adding during a range

Unlike most languages, Go states exactly what happens here. Deleting is safe: if you remove an entry the loop has not reached yet, it is simply never produced. Adding is legal but unpredictable: a new entry "may be produced during the iteration or may be skipped", and that choice can differ from run to run. So delete freely, but if you need to insert, snapshot the keys first and mutate afterwards.

package main

import (
	"fmt"
	"maps"
	"slices"
)

func main() {
	scores := map[string]int{"alice": 90, "bob": 45, "carol": 72, "dana": 30}

	// Deleting during a range is legal: an entry deleted before the loop
	// reaches it is simply never produced.
	for name, score := range scores {
		if score < 50 {
			delete(scores, name)
		}
	}
	fmt.Println(slices.Sorted(maps.Keys(scores)))

	// Emptying the whole map is one builtin (Go 1.21+), no loop needed.
	clear(scores)
	fmt.Println(len(scores), scores == nil)

	// ADDING during a range is legal too, but the new entry may or may not be
	// produced by that same loop -- so snapshot the keys and mutate after.
	grid := map[string]int{"a": 1, "b": 2}
	for _, k := range slices.Sorted(maps.Keys(grid)) {
		grid[k+"2"] = grid[k] * 2
	}
	fmt.Println(slices.Sorted(maps.Keys(grid)))
}

Prints [alice carol], then 0 false, then [a a2 b b2]. The delete-while-ranging filter is deterministic because the decision for each entry depends only on that entry. clear(m) empties a map without replacing it, which is why the second line reports length 0 but scores == nil is false — every other holder of that map sees the same empty map. The last loop ranges a slice of keys, so the four entries it ends up with never depend on iteration timing. One thing that is never safe: writing to a map from another goroutine while this one ranges it — the runtime detects that and panics with concurrent map iteration and map write.

7Nested maps and map[string][]T

Two shapes cover most real data: a map whose values are slices, and a map of maps. For a map[string][]T the inner range is over a slice, which does have an order, so only the outer loop needs sorting. For a map of maps you have to sort at every level, or the nesting reintroduces the randomness one layer down.

package main

import (
	"fmt"
	"maps"
	"slices"
	"strings"
)

func main() {
	// map[string][]T: range the map, then range the slice -- slices ARE ordered.
	tools := map[string][]string{
		"go":   {"gofmt", "go vet"},
		"rust": {"clippy"},
	}
	for _, lang := range slices.Sorted(maps.Keys(tools)) {
		fmt.Println(lang+":", strings.Join(tools[lang], ", "))
	}

	// Appending under a missing key just works: the zero value of []string is
	// nil, and append to a nil slice allocates one.
	tools["zig"] = append(tools["zig"], "zig fmt")
	fmt.Println(tools["zig"], len(tools))

	// Nested map: sort at EVERY level, or only the outer loop is stable.
	sales := map[string]map[string]int{
		"eu": {"de": 3, "fr": 1},
		"us": {"ny": 8, "ca": 5},
	}
	for _, region := range slices.Sorted(maps.Keys(sales)) {
		inner := sales[region]
		for _, city := range slices.Sorted(maps.Keys(inner)) {
			fmt.Printf("%s/%s = %d\n", region, city, inner[city])
		}
	}
}

Prints go: gofmt, go vet, rust: clippy, [zig fmt] 3, then the four eu/de = 3 … us/ny = 8 lines in sorted order. The asymmetry in the middle is the one to remember: append(tools["zig"], …) works on a missing key because reading a map gives the zero value and appending to a nil slice allocates, but the same move on a map of maps panics — sales["apac"]["syd"] = 1 assigns into a nil inner map. Create the inner map first, guarding with a comma-ok lookup.