A custom slog.Handler writes to one shared io.Writer; how do you keep concurrent Handle calls from interleaving?

## Why this is the handler's problem `slog.Logger` does no locking. It builds a `slog.Record` and calls `Handler.Handle`, and if fifty goroutines log at once, fifty goroutines are inside your `Handle` at once. The interface documentation is explicit that a handler must be safe for concurrent use by multiple goroutines. Meanwhile `io.Writer` promises nothing about concurrency: `Write` on an `os.File` such as the process's standard output happens to reach a single syscall, but a `bytes.Buffer` in a test, or any wrapper someone hands your constructor, is not safe at all. So the handler owns the serialisation. ## Two separate hazards **Interleaved bytes.** If `Handle` writes in pieces — one `Write` for the timestamp, one per attribute, one for the newline — then two concurrent records interleave and you get a line with half of each. Even a correct-looking output format is destroyed. The fix is not more locking around each piece, it is fewer writes: assemble everything into one `[]byte` and write it once. **Concurrent access to the writer itself.** Even with one `Write` per record, two goroutines calling `Write` on the same non-thread-safe writer is a data race in the strict sense; the race detector will report it on a `bytes.Buffer`. That is what the mutex is for. ## The shape ```go func (h *handler) Handle(_ context.Context, r slog.Record) error { line := make([]byte, 0, 256) // ... append level, message, h's stored attrs, then r's attrs ... line = append(line, '\n') h.mu.Lock() defer h.mu.Unlock() _, err := h.w.Write(line) return err } ``` The formatting happens before the lock is taken, so goroutines only queue for the duration of one write. If you format inside the critical section, every logging goroutine in the process serialises behind the slowest attribute conversion, and that turns a logger into a contention point under load. A scratch slice per call is the simple version; a handler that wants to avoid a fresh allocation per record can pull the byte slice from a `sync.Pool` — but keep that decision separate from correctness. The correctness rule is one `Write` per record, under the lock. ## Where the mutex must live This is the subtle part, and it is the one interviews probe. `WithAttrs` and `WithGroup` return new handlers, and the usual implementation is `h2 := *h` — a shallow copy of the struct. Everything that must be *shared* with the parent has to be a pointer, because a shallow copy duplicates values and copies pointers. If the field is `mu sync.Mutex`, the copy has its own independent mutex. Now `base.With("a", 1)` and `base.With("b", 2)` are two handlers, each locking its own mutex, both writing to the same `os.Stdout`. Every record still takes *a* lock, so the code looks right, and it will pass a single-logger test — but under load two derived loggers happily write at the same time and the output is corrupted. Copying a `sync.Mutex` by value is also flagged by `go vet`'s copylocks check when it can see it, which is another reason the pointer form is the idiom. Store `mu *sync.Mutex`, allocate it once in the constructor alongside the writer, and let every derived handler carry the same pointer. Parent and children then share exactly one lock guarding exactly one writer, which is the invariant you actually want: the lock's scope is the *writer*, not the handler value. ## Testing it A table test that logs from several goroutines and then checks that every output line parses is worth having, but the sharper test is to run it under the race detector with `go test -race`: a `bytes.Buffer` sink makes any unsynchronised concurrent write an immediate, reported race. Remember what that proves and what it does not — the detector reports races that actually occurred in that run, so the test has to genuinely exercise concurrent logging through *derived* loggers, not just the base one, or the split-mutex bug goes unseen. ## Related decisions you should not confuse with this one Making `Handle` safe is not the same as making it fast, and it is not the same as making it non-blocking. A handler that writes synchronously under a mutex will block its caller when the sink is slow; a handler that hands the record to a background goroutine does not, but then it must clone anything it retains and must decide what happens when its queue is full. Those are design choices layered on top of the basic requirement, which stands either way: concurrent calls to `Handle` must not corrupt the output.