Para que serve o pacote context?

Question

Accepted Answer

O pacote **`context`** carrega **sinais de cancelamento, prazos e valores com escopo de requisição** através de limites de API e goroutines. É o mecanismo padrão para controlar o tempo de vida das operações — especialmente para cancelar trabalho e propagar timeouts através de uma cadeia de chamadas de funções.

## O problema central que resolve

```text
A request starts work across many goroutines/functions (DB query, API call, etc.).
If the client disconnects or a timeout hits, you want to CANCEL all that work
so goroutines don't keep running uselessly (wasting resources / leaking).
→ context propagates the "stop now" signal down the entire call chain.
```

## Criando contexts

```go
ctx := context.Background()          // the root context (top of the tree)
ctx := context.TODO()                 // placeholder when unsure

// with a timeout — auto-cancels after the duration
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()                        // ALWAYS call cancel to release resources

// with manual cancellation
ctx, cancel := context.WithCancel(context.Background())
// call cancel() to signal cancellation

// with a deadline (specific time)
ctx, cancel := context.WithDeadline(ctx, time.Now().Add(time.Minute))
```

`WithTimeout`/`WithDeadline`/`WithCancel` derivam um context filho que pode ser cancelado; você deve fazer `defer cancel()` para liberar seus recursos.

## Respondendo ao cancelamento

```go
func doWork(ctx context.Context) error {
    for {
        select {
        case <-ctx.Done():            // fires when cancelled or timed out
            return ctx.Err()           // returns context.Canceled or DeadlineExceeded
        case work := <-jobs:
            process(work)
        }
    }
}
```

Funções verificam `ctx.Done()` (um canal que fecha no cancelamento) e param prontamente — é assim que o cancelamento realmente se propaga.

## Passando context através de uma cadeia de chamadas (a convenção)

```go
// ctx is conventionally the FIRST parameter, named ctx
func handler(ctx context.Context, ...) {
    data, err := fetchFromDB(ctx, id)   // pass it down — DB call honors cancellation
}
func fetchFromDB(ctx context.Context, id int) (...) {
    row := db.QueryRowContext(ctx, ...)  // standard-library APIs accept context
}
```

Context flui para baixo da pilha de chamadas como primeiro parâmetro, então o cancelamento alcança cada camada (incluindo chamadas de DB/HTTP da biblioteca padrão que aceitam um context).

## Valores com escopo de requisição (use com moderação)

```go
ctx = context.WithValue(ctx, requestIDKey, "abc-123")   // attach a value
id := ctx.Value(requestIDKey)                            // retrieve it downstream
// ⚠️ for request-scoped metadata (request IDs, auth) — NOT for passing regular params
```

## Por que isso importa

O pacote `context` é fundamental para escrever serviços Go robustos e de nível de produção — é a forma padrão e idiomática de lidar com **cancelamento e timeouts** através de goroutines e limites de API.

Seu valor principal é evitar trabalho desperdiçado e vazamentos de recursos: quando um cliente se desconecta, um prazo passa, ou um servidor desliga, context propaga o sinal de cancelamento para que todas as goroutines e operações criadas para essa requisição parem prontamente em vez de rodar inutilmente (uma defesa chave contra vazamentos de goroutines).

É onipresente em Go real — servidores HTTP, chamadas de banco de dados, gRPC e a maioria das bibliotecas em rede aceitam um `context.Context` como seu primeiro parâmetro.

Compreender como criar contexts (`WithTimeout`/`WithCancel`), responder ao cancelamento (`<-ctx.Done()`), a regra obrigatória de chamar `cancel()`, e a convenção de passar context através de cadeias de chamadas é essencial para qualquer trabalho sério de backend em Go e é um tópico comum em entrevistas.