
`os.Getenv` returns the value of an environment variable or an empty string if the variable is not set. `os.LookupEnv` returns a second boolean that tells you which case you have.

<ExamplePair>
<ExampleProse>

`os.Getenv` is the quick read. `os.LookupEnv` returns `(value, ok)` - use it when an empty string is a valid value and you need to distinguish it from an absent variable.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "os"
)

func main() {
    // Simple read - empty string if not set
    home := os.Getenv("HOME")
    fmt.Println("HOME:", home)

    // Distinguish "not set" from "set to empty"
    val, ok := os.LookupEnv("MY_API_KEY")
    if !ok {
        fmt.Println("MY_API_KEY is not set")
    } else {
        fmt.Printf("MY_API_KEY = %q\n", val)
    }
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`os.Environ` returns all environment variables as a `[]string` in `KEY=VALUE` form. `os.Setenv` and `os.Unsetenv` mutate the process environment - changes are visible to child processes spawned after the call.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "os"
    "strings"
)

func main() {
    os.Setenv("APP_ENV", "production")
    defer os.Unsetenv("APP_ENV")

    // os.Environ returns all KEY=VALUE pairs
    for _, entry := range os.Environ() {
        if strings.HasPrefix(entry, "APP_") {
            fmt.Println(entry)
        }
    }

    // os.Expand substitutes ${VAR} references
    template := "running in ${APP_ENV} mode"
    fmt.Println(os.ExpandEnv(template))
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
Use `os.LookupEnv` instead of `os.Getenv` when you need to distinguish "not set" from "set to empty string" - a blank `DATABASE_URL` and a missing `DATABASE_URL` are different failure modes. Parse and validate all required environment variables at startup and fail fast with a descriptive error: discovering a missing variable on the first request is worse than crashing on boot. A common pattern is a `config.Load()` function called in `main` that reads every required var with `LookupEnv`, collects all missing names into a slice, and returns a single error listing them all. Libraries like `kelseyhightower/envconfig` or `caarlos0/env` automate this: they populate a struct from env vars and validate required fields in one call. For secrets (database passwords, API keys), prefer a secrets manager (AWS Secrets Manager, HashiCorp Vault) that injects values as env vars at container start rather than baking them into images or config files.
</InProduction>


os.Getenv reads env vars; os.LookupEnv distinguishes "not set" from "set to empty string" - critical for required config validation at startup.

Environment Variables


`log/slog` (introduced in Go 1.21) is the standard structured logging package. It replaces ad-hoc `log.Printf` calls with key-value pairs that log aggregators can index and query.

<ExamplePair>
<ExampleProse>

`slog.Info`, `slog.Error`, `slog.Debug`, and `slog.Warn` are the four level functions. Each accepts a message and alternating key-value pairs. The default handler writes human-readable text to stderr.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "log/slog"
    "os"
)

func main() {
    slog.Info("server starting", "port", 8080, "env", "production")
    slog.Debug("cache miss", "key", "user:42")  // filtered if level > Debug
    slog.Warn("rate limit approaching", "remaining", 10)
    slog.Error("database unreachable", "host", "db.internal", "err", os.ErrDeadlineExceeded)
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Switch to a JSON handler for production. Use `slog.With` to create a child logger with pre-attached fields - every log line emitted from that logger includes those fields automatically.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "log/slog"
    "os"
)

func main() {
    // JSON handler for structured output (log aggregators expect this)
    logger := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
        Level: slog.LevelInfo,
    }))
    slog.SetDefault(logger)

    // Attach request-scoped fields once; every subsequent log includes them
    reqLogger := logger.With("request_id", "abc-123", "user_id", 42)
    reqLogger.Info("request received", "method", "GET", "path", "/api/users")
    reqLogger.Info("request complete", "status", 200, "duration_ms", 14)
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
Use `log/slog` for all new code - it is the stdlib answer to zerolog and zap for most workloads. Structured logs (JSON) are required for log aggregators like Datadog, CloudWatch Logs, and Grafana Loki; a `log.Printf` string line is effectively unsearchable at scale. Use `slog.With` to attach request-scoped fields (trace ID, user ID, tenant ID) at the handler entry point so every log line in a request includes them without threading the logger through every function call. Set the minimum level via `slog.HandlerOptions.Level` - debug logs in production are a compliance risk (they may contain PII or secrets) and a throughput risk (log volume can exceed ingestion limits under load). For high-throughput services where slog's allocation overhead is measurable, zerolog or zap remain valid choices, but profile first. Never log sensitive fields (passwords, tokens, full credit card numbers) at any level; redact at the point of construction.
</InProduction>


log/slog (Go 1.21) provides structured logging with JSON output for production and human-readable text output for development - attach request-scoped fields with slog.With.

Logging


`flag.NewFlagSet` creates an independent flag parser. Dispatch on `os.Args[1]` to select the subcommand, then call `Parse` on the matching `FlagSet` with the remaining arguments.

<ExamplePair>
<ExampleProse>

Create a `FlagSet` for each subcommand. Each set parses only its own flags, so `--output` on `build` does not conflict with `--output` on `deploy`.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "flag"
    "fmt"
    "os"
)

func main() {
    buildCmd := flag.NewFlagSet("build", flag.ExitOnError)
    buildOutput := buildCmd.String("output", "app", "output binary name")

    deployCmd := flag.NewFlagSet("deploy", flag.ExitOnError)
    deployEnv := deployCmd.String("env", "staging", "target environment")

    if len(os.Args) < 2 {
        fmt.Println("usage: tool <build|deploy> [flags]")
        os.Exit(1)
    }

    switch os.Args[1] {
    case "build":
        buildCmd.Parse(os.Args[2:])
        fmt.Printf("building binary: %s\n", *buildOutput)
    case "deploy":
        deployCmd.Parse(os.Args[2:])
        fmt.Printf("deploying to: %s\n", *deployEnv)
    default:
        fmt.Printf("unknown subcommand: %s\n", os.Args[1])
        os.Exit(1)
    }
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Each `FlagSet` exposes its own `Args()` method returning positional arguments that follow the flags. Subcommand positional arguments do not mix with the top-level `os.Args`.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "flag"
    "fmt"
    "os"
)

func main() {
    addCmd := flag.NewFlagSet("add", flag.ExitOnError)
    force := addCmd.Bool("force", false, "overwrite if exists")

    if len(os.Args) < 2 {
        fmt.Fprintln(os.Stderr, "usage: store <add> [flags] <files...>")
        os.Exit(1)
    }

    switch os.Args[1] {
    case "add":
        addCmd.Parse(os.Args[2:])
        files := addCmd.Args() // positional args after flags
        fmt.Printf("force: %v, files: %v\n", *force, files)
    default:
        fmt.Fprintf(os.Stderr, "unknown: %s\n", os.Args[1])
        os.Exit(1)
    }
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
The standard library `flag.FlagSet` approach is sufficient for tools with two or three subcommands. For larger CLIs (nested subcommands, shell completion, manpage generation, rich help formatting), cobra or urfave/cli are the production standard - they are what the Go, Docker, and Kubernetes CLIs use. Structure subcommands as separate packages to keep `main` thin: each subcommand package exports a `Run(args []string) error` function, and `main` dispatches to it. This makes subcommands independently testable without going through `os.Args`. Always handle the case where `os.Args` has fewer than two elements before indexing into `os.Args[1]` - a bare invocation without a subcommand should print usage and exit cleanly, not panic.
</InProduction>


flag.NewFlagSet creates a per-subcommand flag set, enabling tools with subcommands like "git commit" or "docker run" where each subcommand has its own flags.