What does Go's `defer` statement do, and when does the deferred call actually run?

## What `defer` actually is `defer` takes a **call expression** and postpones it. The line `defer f.Close()` does not close the file where it is written; it registers that call against the function currently running, and the call is executed when that function finishes. It must be a call, not a function name: `defer f.Close()` compiles, `defer f.Close` does not. ## The unit is the function, not the block This is the single most common misreading. Go's `defer` is **function-scoped**. A `defer` inside an `if`, a `for`, or a bare `{ }` block does not fire when that block ends — it waits for the enclosing function to return. ```go func demo(path string) { defer fmt.Print("1") if path != "" { defer fmt.Print("2") // NOT at the closing brace of the if } fmt.Print("body ") } ``` `demo("x")` prints `body 21`. Both deferred calls wait until `demo` returns. Engineers arriving from languages where a scope-exit hook is block-scoped (C++ destructors, Python's `with`, Java's try-with-resources) trip on this constantly, and it is the direct cause of the classic "defer inside a loop keeps every file open" bug. ## Ordering: last-in-first-out Deferred calls run in the **reverse of the order they were registered**. The function keeps them in a stack; the last one registered is the first one executed. In the example above `"2"` was registered second, so it prints first. LIFO is not an arbitrary choice — it makes cleanup mirror acquisition. If you open a file, then lock a mutex protecting the index, then start a timer, the reverse order tears them down in the only order that is safe: nothing is released while something registered later still depends on it. Written in the idiomatic style, acquisition and release sit adjacent: ```go f, err := os.Open(path) if err != nil { return err } defer f.Close() mu.Lock() defer mu.Unlock() ``` A reviewer can see, on one line each, that every acquired resource is released. ## Which exit paths run defers Deferred calls run: - on a normal fall-off-the-end return; - on an explicit `return`, including an early return from a guard clause deep in the function — this is why `defer` is more reliable than a cleanup block at the bottom, which a new `return` silently skips; - while a goroutine is unwinding after a panic, which is what makes deferred cleanup survive a crash on that path. They do **not** run when the process is terminated outright. `os.Exit` exits immediately without touching pending deferred calls, and anything built on it inherits that behaviour — `log.Fatal` and friends call `os.Exit`, so a `defer f.Close()` above a `log.Fatalf` never runs. If you need cleanup, return an error up to a small `main` that decides the exit code, rather than exiting from deep inside the call tree. A deferred call also belongs to **one function in one goroutine**. Starting a goroutine does not carry the caller's deferred calls into it, and a goroutine that never finishes never runs the calls its own function deferred. ## The order of events at return When a function returns, three things happen in sequence: the return values are set, then the deferred calls run (newest first), then control returns to the caller. The middle step is genuinely *after* the result has been assigned, which is why a deferred closure can still adjust a **named** result before the caller sees it. ## Everyday uses Closing a file or an HTTP response body, unlocking a mutex, stopping a `time.Ticker`, restoring a global or a config value you temporarily changed in a test, and marking a span of work finished. The common thread: something you must undo exactly once, on every path out, written next to the thing that made it necessary. ## Two caveats that bite First, the **arguments** of a deferred call are evaluated at the `defer` statement, not at return — so `defer fmt.Println(x)` prints the `x` of that moment. Second, because `defer` is function-scoped, registering one per iteration of a long loop accumulates work and holds every resource open until the whole function ends; per-item cleanup needs a per-item function call.