Краткий ответ

Запись в nil-map приводит к панике, тогда как чтение, проверка наличия ключа, получение длины, перебор и удаление ключа безопасны. Чтобы добавлять элементы, map нужно заранее инициализировать через make или присвоить уже созданную map.

Исторический контекст

Go активно использует нулевые значения, чтобы объявление переменной сразу давало предсказуемое состояние без обязательного конструктора. Для map это означает, что неинициализированное значение можно безопасно читать как пустую map, но оно не имеет внутреннего хранилища для записи.

Такой подход упрощает чтение данных и проверку необязательных полей. При этом граница между чтением и изменением остаётся явной: операция, требующая выделения хранилища, должна выполняться над созданной map.

Постановка проблемы

Если поле map не заполнено при разборе конфигурации, код может успешно прочитать из него значение или проверить наличие ключа, но упасть при попытке добавить настройку. Паника возникает во время выполнения, поэтому она может проявиться только на конкретной ветке обработки.

Важно отличать nil-map от пустой созданной map. Обе не содержат элементов и имеют длину ноль, но только вторая допускает запись.

Подробное решение

У nil-map чтение отсутствующего ключа возвращает нулевое значение типа элемента. Одновременная форма с проверкой второго результата позволяет отличить отсутствие ключа от наличия ключа, хранящего нулевое значение.

Безопасны len, перебор через range и delete. Запись по ключу, включая составные операции изменения значения, требует инициализированной map и на nil-map вызывает панику.

package main

import "fmt"

func main() {
    var m map[string]int
    fmt.Println(len(m), m["retries"])
    delete(m, "retries")
    m["retries"] = 3 // panic: assignment to entry in nil map
}

make(map[string]int) создаёт пустую, но готовую к записи map. Присваивание map переменной копирует дескриптор структуры данных, поэтому после инициализации несколько переменных могут ссылаться на одно хранилище; это отдельное свойство map, не меняющее правила nil-map.

Ситуация из практики

Сервис получает необязательное поле с дополнительными параметрами. Если поле отсутствует, декодер оставляет map равной nil, а обработчик затем без проверки добавляет вычисленный параметр и получает панику.

Вариант с проверкой перед каждой записью локализует исправление, но легко приводит к дублированию и пропуску веток. Вариант с безусловной инициализацией сразу после разбора гарантирует готовность структуры к изменению, но уничтожает различие между «поле отсутствовало» и «поле было явно пустым».

Если это различие не нужно, предпочтительно инициализировать map при создании конфигурации или перед первой записью. Если оно важно для бизнес-логики, nil следует сохранять до момента, когда код явно определит, нужно ли создавать хранилище.

Что кандидаты часто упускают

Вопрос: Можно ли безопасно передать nil-map в функцию, которая только читает данные?

Ответ: Да. Передача map копирует её дескриптор, а чтение nil-map корректно возвращает нулевые результаты. Однако функция всё равно упадёт, если попытается записать элемент.
Вопрос: Отличаются ли nil-map и пустая map при сравнении с nil?

Ответ: Да. Nil-map равна nil, а пустая map, созданная через make, — нет. При этом обычное сравнение двух map между собой запрещено: сравнивать их можно только с nil.
Вопрос: Безопасно ли одновременно читать nil-map из нескольких горутин?

Ответ: Само чтение nil-map не создаёт хранилище и не изменяет её, поэтому проблема записи в nil-map не возникает. Но для обычной map совместный доступ с конкурентной записью требует синхронизации; nil-состояние не отменяет общих правил конкурентного доступа к map.