Answer.

Background:

In Go, there are no universal containers like a generic map by default — only starting from Go 1.18 did generics appear, but for dynamic structures, map[string]interface{} has often been used historically and continues to be used, allowing the storage of values of any type by string key.

Problem:

This pattern — analogous to a dictionary/JSON object — is commonly found everywhere for serialization, working with middleware, and handling data without a defined structure (for instance, JSON parsing via encoding/json). However, accessing values requires manual type assertions and caution with implicit values and missing keys.

Solution:

Use map[string]interface{} where the structure of incoming data is unknown. Carefully check for the presence of keys, perform type assertions only after the exists-idiom. It’s better not to keep such maps "deep" in business logic, but rather as adapters at the system boundaries.

Code example:

obj := map[string]interface{}{
    "int": 42,
    "str": "hello",
    "flag": true,
}

if v, ok := obj["int"]; ok {
    n, success := v.(int)
    if success {
        fmt.Println(n)
    }
}

Key features:

Allows storing values of any type in a single map.
Requires strict control when performing type assertions and reading values.
Often used for JSON/HTTP APIs, but not recommended for core business logic.

Trick questions.

Can you safely access a value by key in map[string]interface{} if the key is missing?

No, this will yield the "zero value" (nil) for interface{}, and type assertion to a specific type will cause a panic.

What happens during the serialization of map[string]interface{} with nested slices or other maps?

JSON serialization will correctly handle the structure, but if there are types not supported by default (channels, functions), it will result in a marshaling error.

Can you compare two values in map[string]interface{} using ==?

No, interface{} can only be compared if the underlying value is comparable. If a map or slice is involved, it will panic during comparison.

Common mistakes and anti-patterns

Do not perform type assertions assuming the type is always correct.
Keep "raw" maps in application logic, rather than at the boundaries/ during parsing.
Do not check for key existence before reading.

Real-life examples

Negative case

In an application, all logic is built on map[string]interface{} objects, and each controller/service passes them deeply through calls.

Pros:

Flexible, quick to get a prototype started.

Cons:

No type checking — bugs appear at runtime.
Hard to read and maintain code.

Positive case

map[string]interface{} is used only for working with external interfaces, incoming/outgoing data, and then translated into proper structures.