Why start with [][]int{} instead of var levels [][]int?

Both work with append and both have length 0, but they differ when the result is encoded: json.Marshal writes a nil slice as null and an empty one as []. For the empty tree a checker comparing JSON would see null instead of []. Starting from [][]int{} makes the empty result a real, empty slice. Inside the loop var next []*TreeNode is fine, because a nil next only ends the loop.

Why declare the closure with var before assigning it?

A function literal cannot refer to the variable it is being assigned to in the same statement: walk := func(…) { walk(…) } fails with undefined: walk, because walk is not in scope until the statement ends. Declaring var walk func(node *TreeNode, depth int) first and assigning on the next line puts the name in scope inside the body. A package-level helper function with levels passed by pointer works too.

Is levels[depth] = append(levels[depth], v) safe when levels itself grows?

Yes. append(levels, []int{}) may move the outer slice to a new backing array, but it copies the row headers across, and each row has its own backing array. The closure always reads levels fresh, so levels[depth] names the current header of that row, and writing the result of append back into it keeps the outer slice up to date.

Can the recursive version overflow the stack in Go?

Only at extreme depths. A goroutine stack starts small and grows as needed up to a 1 GB ceiling on 64-bit systems, so the recursive walk handles chains far deeper than the 200 levels here. Past the ceiling the program dies with fatal error: stack overflow, which recover cannot catch. The slice-based BFS has no depth limit at all.

How do I get the levels as a zigzag, alternating direction?

Reverse every odd row of the result in place: for i := 1; i < len(levels); i += 2 { r := levels[i]; for a, b := 0, len(r)-1; a < b; a, b = a+1, b-1 { r[a], r[b] = r[b], r[a] } }. For [6, 2, 9, 1, 4, nil, 12] that gives [[6] [9 2] [1 4 12]]. Since Go 1.21, slices.Reverse(levels[i]) does the inner loop for you.

Binary Tree Level Order Traversal in Go (Golang): DFS and BFS Solutions

level_order.go

Go 1.26

Not run yet

+ 7 hidden

Input

root = [6, 2, 9, 1, 4, null, 12]

Expected

[[6], [2, 9], [1, 4, 12]]

The root 6 is a level of its own, its children 2 and 9 form the next one, and the grandchildren 1, 4 and 12 the last. 9 has no left child, so the third level simply has three values.

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level

1 · Depth-first: file each value under its depth

2 · Breadth-first: one queue round per level