What does json.Decoder.DisallowUnknownFields change about a Decode call that reads an unexpected key?

## What the option does `json.Decoder` is the streaming decoder you get from `json.NewDecoder(r)` over any `io.Reader`. Calling `DisallowUnknownFields()` on it, before `Decode`, changes exactly one behaviour: an object key that matches no field of the destination struct stops being skipped and becomes a decode error instead. ```go dec := json.NewDecoder(f) dec.DisallowUnknownFields() var c Config if err := dec.Decode(&c); err != nil { return fmt.Errorf("config: %w", err) } ``` The error is an ordinary error value, not a dedicated exported type, and its text carries the key name: `json: unknown field "maxConnnections"`. That name is the whole value of the feature — it turns "my setting had no effect" into a message that says which key nobody understood. ## The three details that catch people out **It lives on the Decoder, not on Unmarshal.** There is no `json.UnmarshalStrict`, and no option argument on `json.Unmarshal`. When what you have is a `[]byte` — a request body already read, a file already loaded — you wrap it: `json.NewDecoder(bytes.NewReader(b))`, set the flag, then `Decode`. That is the standard way to get strict behaviour on bytes. **Decoding continues, and only the first unknown key is named.** The decoder records the problem and carries on through the rest of the document, so a file with four unrecognised keys yields one error mentioning one of them. Fix it, rerun, and the next one appears. Just as importantly, the destination struct is not left untouched: the keys that did match have already been assigned. A struct populated by a decode that returned an error is not a partially-valid configuration to fall back on — discard it and keep whatever you were using before. **Its scope is narrower than "strict".** Enabling it does not make the decode strict in general. It says nothing about: - *Duplicate keys.* An object containing the same key twice is accepted; the later value overwrites the earlier one and no error is raised. - *Case variants.* A key that differs from the field name only in letter case matched a field, so it is not unknown and passes. - *Missing keys.* There is no notion of a required field; an absent key leaves the Go zero value, which the decoder considers a perfectly good outcome. - *Extra content after the value.* `Decode` reads one JSON value from the stream; whatever follows it is simply not read by that call. If you describe the option to a colleague as "strict JSON", they will assume all four of those are covered. Describe it as what it is: an unknown-key check. ## Where to turn it on The natural home is a boundary you control and can fail at cheaply. Loading a config file at process startup is the strongest case: a typo becomes a startup failure with the key printed, before the process takes any traffic, and the operator gets an unambiguous message instead of a mystery. Validating a rendered config in CI is stronger still, because nothing is deployed at all. An HTTP handler decoding a request body is a more mixed case. Rejecting a request because the client sent a field you do not know is a contract decision, not a hygiene one — it makes your API brittle to any client that adds a field before you do. Many teams run strict decoding on internal, self-generated documents and lenient decoding on anything a third party sends. ## Getting the report without the failure The option has no warn-only mode: it either errors or it does not. When you want the name of the offending key but cannot afford to fail, decode twice from the same bytes — once leniently into your struct, which is the value you use, and once strictly, purely to see what it complains about, logging the key. The second decode costs one more pass over a small document and converts an invisible failure into a log line an operator can act on.